This is exactly what I've been working on; I call them 'SiteRoot' objects :-) Nowhere near done, and I'd love to collaborate.
jim, evan, this is exactly what i've been working on too! :-) i call them VirtualHostFolders... the thing i have works, it is a product and a couple of patches to Zope, but it has some issues. i'll post the code this evening, after i clean it up a bit, it might be useful to you. the SiteObject proposal is great, my comments follow....
http://www.zope.org/Members/jim/SiteObjectProposal
Comments?
i've approached this a bit different from either jim's or evan's ways. o Most functionality lives in the VirtualHostFolder Product -- minimal patches to Zope source o VirtualHostFolders derive from the Folder Object -- with an additional property, IPaddress (this will eventually be a list of IPaddresses?) o Small patch to ZServer.HTTPRequest -- so it places the actual socket IP and Port numbers into the request's environment (HTTP_SOCKET_IP and HTTP_SOCKET_PORT) -- i didn't use HTTP_HOST for mapping since it is symbolic; i wanted to have a 1:1 mapping from IP address to path o Small patch to ZPublisher -- allows registration of multiple remapper methods. takes as arguments the object path and the REQUEST, returns a new (remapped) path. -- doesn't solve the generalized remapping problem, but allows a plug-in solution without further patches. -- i map an IP number to a Zope object path, by adding a path prefix to the URI in ZPublisher. this would allow a similar approach to be used for other protocols, like FTP. o new persistent Remapper object -- holds dictionary of IP:path_prefix mappings -- Issue: how and where to store this, since it needs to be notifies upon creation or deletion or changes to VirtualHostFolders, o allows other Remapper objects to be registered -- to do other kinds of object path remapping this approach seems to solve several problems, while creating others. :-) there are no changes access control and permissions. acquisition happens normally. (i think.) one problem or issue i've been grappling with is: where to you store the dictionary of IPaddresses and path_prefixes? it needs to be persistent, and should probably be a Zope object so it can have transaction and version support and other good stuff. but the VirtualHostFolder instances need to talk with it when they are created, changed, or deleted. right now my VirtualHostFolder product does a terrible kludge :-) and stores the Remapper object it its own ZODB in its own FileStorage object in the var/ directory. ugh! i did that because i haven't figured out how to store or open a Zope object in the currently open database from the product's __init__.py file... if this is possible, it seems like the right thing to do would be to make the Remapper object a sub-object of the VirtualHostFolder product, which would then get acquired (?) by VirtualHostFolder instances...? i'm not sure here. why i did it this way: if you take the SiteObject or SiteRoot ways, you still need a centralized dictionary or IPaddress:path mappings... at least it seems this way to me. for performance reasons you don't want to go looking all over the ZODB hierarchy for every request. :-) so if you need a centralized place for the dictionary, you might as well go the route of just using special folder-like objects that can be put anywhere in the ZODB hierarchy... it seems the most Zope-like, and it seems to require the least changes to Zope and to how people understand Zope. i thought about making a product that you could just drop into a folder to make it a Virtual Host, but then... you get the issues of needing to make these invisible to non-managers, you still need a centralized dictionary, etc. anyway, i'll clean my code up and post it this evening (with patches too) for people to look at and comment on. whatever way is eventually chosen, i think virtual hosting is a Good Thing and will help make Zope better and better... :-) cheers adam -- Adam Feuer adamf@pobox.com