[Zope-dev] PROPOSAL: Site objects
Adam Feuer
adamf@pobox.com
Tue, 21 Sep 1999 12:51:52 -0700
> 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