[Zope3-dev] FTP/PUT/file-system-reprentation progress

Tres Seaver tseaver@zope.com
07 Feb 2003 18:22:33 -0500


On Fri, 2003-02-07 at 12:20, Jim Fulton wrote:
> 
> Hi,
> 
> This is to provide an update on some work I've been doing getting FTP,
> PUT, and, eventually, WebDAV working.
> 
> As far as I know, FTP is now working. I think that there are some cases
> where error handling isn't quite right. If you see anything, please let
> me know.
> 
> I also have HTTP PUT working. This required adding the foundation for any
> non-browser HTTP method. (Browser methods are GET, HEAD, and POST.
> BTW, I also implemented HEAD.) This foundation will also support WebDAV,
> which uses many additional HTTP methods.
> 
> I've ripped out the old VFS framework, which was way too Unix file-system
> specific and replaces with a simpler, I think adapter framework that is
> based on mimimal file-system representatin ideas.
> See zope.app.interfaces.file. This framework supports FTP and PUT and will
> play a part in object-system <-> file-system synchronization. (Those of you
> who lobbied for more commonality accross these should be happy. :)
> 
> I also changed the site-management objects to provide simple browsing
> interfaces to facilitate combined browsing and editing with tools like
> Mozilla Composer, Amaya, and WebDAV tools.
> 
> I'd like to describe a scenario (using old terminoligy, I'm afraid)
> that illustrates a part of what I'm trying to achiev.
> 
> As a site developer, I can create a view sub-package in a site's
> default package. A view sub-package is a folder that can only contain
> templates. When you add a template to the view sub-package, it
> automatically registered as a view using configuration parameters
> defined in the subpackage as a whole.  Suppose my subpackage
> is named "folder" and is configured so that it's templates are
> configured to be views for IFolder. The path to the view package is:
> 
>    /++etc++Services/Packages/default/folder
> 
> I can visit that path with an FTP client and save a zpt source
> file, named v1.html.  Someone can then visit a url like:
> 
>    /somefolder/someotherfolder/v1.html
> 
> and see the view.
> 
> I could also browser to:
> 
>    /++etc++Services/Packages/default/folder/v1.html
> 
> with Mozilla, or Amaya to view the template source as an
> html document.  I can choose to edit the document with
> Mozilla Composer. When I save my changes, they are written
> back and reflected in the views.
> 
> Note that no source port was needed (nothing up my sleeve ;).

Heh, you performed a "magician's force" there:  you *know* that you want
the source, because you are publishing the template in a special place: 
it is delineated differently, but you still have a "funny" URL.  You do
get away (here, anyway) with running only one HTTP publisher.

> The reason that a GET of
> /++etc++Services/Packages/default/folder/v1.html
> will always return the source of the template, while a GET of:
> 
>    /somefolder/someotherfolder/v1.html
> 
> will return the template rendered for someotherfolder.
> 
> We still need file-represntation adapters for a few more content types,
> like dtml pages and sql scripts.  These would make good small projects
> for some one. :)

Since the "magician's force" isn't going to be available for objects in
content space, we are still stuck here:  how is the GET view for a piece
of content going to know whether to render the object or not?  Sniffing
HTTP_AGENT is a strategy Chris and Fred have been experimenting with
for Zope 2.7, but it is still tricky.  If WebDAV clients implemented the
'document_src' protocol....nah, that's a pipe dream. :)

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com