Itamar Shtull-Trauring wrote:
> Chris Withers wrote:
> > PS: The XML-RPC stuff could just be given the nwe view permission for
> > objectIds, if it REALLY needs it... although this would mean the
> > docstrings thing would have to eb replaced, which isn't necessarily a
> > bad thing ;-)
> Yes, it really needs it. My XML-RPC uploading interface to Zope needs to
> know what's in a folder - so it needs objectIds. How else am I supposed to
> browse through the Zope tree? I could have users install a method, but this
> is a very generic need (browsing the object tree) and should be built in.
It occurs to me that there are two distinct "views" of the Zope tree.
1. The developer's / content manager's view
This is what we have now.
2. The end-user's view
Taking HTTP as an example, this consists of the set of URLs that
are available for access via the web. Other URLs should return a
404 Not Found, even if they are available as part of the
developer's view (point 1).
Taking HTTP alone, for simplicity of expression; I suppose what I'm
asking for is that there are two HTTP servers for one Zope instance. The
one on port 80 (for example) only responds to those URLs that are for
public viewing. The one on port 8081 (for example) responds to any
request that makes sense to map onto an object or attribute.
The same scheme can be applied to FTP -- you choose whether a particular
FTP server presents the "public" view, or the "developer" view.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -