[Twisted-Python] Bloody Twisted Tree (VFS)

Andy Gayton andy at thecablelounge.com
Mon Jul 7 23:02:06 EDT 2008

On Sun, Jul 6, 2008 at 11:12 AM,  <glyph at divmod.com> wrote:
> One related thing that we spoke about in person was pushing this negotiation
> of file-system features backwards to the initialization step, so that
> applications which needed unusual filesystem attributes could fail quickly
> with a clear error message if they weren't supported by the underlying
> platform. ("WebDAV requires extended filesystem attributes, and your
> backend, SFTP, does not provide that feature.", "txGnuStow requires symbolic
> links, and your backend, the Microsoft Windows filesystem, does not provide
> that feature.")


> One thing we didn't talk about in person: handling extremely large
> directories.  We had spoken about children() returning a Deferred of a list;
> I think it would be nice if it actually had a producer/consumer API of its
> own.  Maybe this is too much of a corner case to worry about in average
> applications (i.e. we could provide a give-me-a-deferred convenience API)
> but it would be nice if it were *possible* to implement things that were
> efficient against really big networked directories.

I really like these two ideas.  I've noted them down work on.  I think
we agree though that we could get a release out first, and then look
to add these?

> However, this reminds me about another concern which I did not remember to
> raise while Andy was here.  Should this really be twisted.<anything> at all?
>  I'd like twisted <x> "dot products" to generally be an application which
> does something <x>-ish.  I'm aware that not every package follows this rule,
> but the ones that don't are either (A) unmaintained and slated for removal,
> or (B) part of the core, not independent subprojects, as "vfs" seems slated
> to be.
> Put a different way: what should 'twistd tree' do?  My suggestion would be a
> simple multi-protocol file server: HTTP, FTP (although probably disable that
> by default), SFTP, maybe a "native" protocol for providing a generalized
> backend for any Twisted application that uses the 'tree' API, so that we can
> write a proxy that exposes every arbitrary combination of features from the
> protocols it's talking to.

I remember a chat I was having with you back in PyCon 2007, about
expanding twistd's command line interface to be able to multiplex
together several different services.

Having a collection of backend implementations available to use with
this would be cool.  But yeah, this could still be be provided without
using a twisted.<x> package.

Here's the vfs plugin so far:
-- Options.longdesc talks about the above idea.  I'm ok either way on


More information about the Twisted-Python mailing list