path module

[Ian Bicking]

On Fri, 2003-07-25 at 20:10, Van Gale wrote:
> Interesting, I started a project modifying Jason's Path module to work 
> on subversion trees as well.  I didn't get too far before putting the 
> project on a back-burner so I'm glad to hear someone else is thinking 
> the same way :)
> 
> My extensions to Path included an additional argument to "open" that 
> included a version number, and a mechanism for retrieving some kind of 
> "metadata" associated with the file.

It's interesting that different kinds of filesystems (or
filesystem-like-things) have very different kinds of metadata
available.  Like last-modified, last-accessed, inode (identity),
version, title, branch, mimetype, log message, etc.  And then there's
information that's not quite metadata... like <link ref> data, or the
volume name, the host, etc.

I feel like a common interface for these different filesystems should
somehow degrade well in terms of metadata, or expedite introspection in
some fashion.

The differences on the client side are probably easier to handle, as
they can be handled by the constructor, which might look different for
different filesystems.  Like url('http://whatever', user='bob',
password='secret', proxy='http://myproxy'), or
cvs(pserver='cvs.sourceforge.net', repository='python').  Or should
there be a string-based representation (i.e., URIs)?  Of course for
symmetry then __str__ would always return a URI, but for many
circumstances we'd prefer a more concise notation, like a filesystem
path (though most other cases would be acceptable squeezed into URIs).


I'd have placed the version in the object itself, not as an argument to
open.  Then you'd want to query for alternate versions, most recent
version -- maybe some version identifier that meant most recent... a
similar situation might be language negotiation with an HTTP file.

  Ian