[summerofcode] FileSystemVirtualization - Ideas

[Narayan Newton]

On 6/5/05, holger krekel <hpk at trillke.net> wrote:
> 
> Hi Narayan,
> 
> On Sat, Jun 04, 2005 at 21:51 -0700, Narayan Newton wrote:
> > I am looking to apply for implementing the "FileSystemVirtualization"
> > project and would like some feedback on a couple ideas. I could see this
> > project working two ways. The first would be fairly simple. It would 
> involve
> > creating a 'generic' class to represent a file system. For the sake of
> > argument, lets call it the FileSystem class. (I am known for my original
> > names) This class would have various methods defined that you need on a 
> FS:
> > write, read, listdir, open..etc. Children of this class would implement
> > various types of file systems. For example, there could be a 
> SvnFileSystem,
> > CvsFileSystem, MySQLFileSystem...etc. These would each implement the 
> class
> > in whatever way they needed to make it work. This would allow programs 
> to
> > use many different file systems easily.
> 
> I like this idea.
> 
> > The other idea would be to build a full-scale vfs system. This would 
> work in
> > much the same way, except there would be a "master" class and a defined 
> uri
> > standard.
> 
> I wouldn't neccessarily mixin URI schemes into the vfs idea.
> It seems more important to have clear and documented semantics
> at API level and to make sure (by writing lots of tests) that
> the semantics work reasonably well across fileystem
> implementations.
> 
> Adding an URL scheme on top of such an API and its
> implementations shouldn't be hard, though. Btw, I don't see a
> connection to inheritance requirements there. It's surely possible
> to just have a dictionary of scheme->urlhandler mappings
> without requiring the 'urlhandler' to even be a class.
> 
> cheers,
> 
> holger
> 

That was my concern with the second idea. While it seemed more 'complete', 
it also seemed like a bit too much. Defining a uri construct would probably 
not go over well with kde/gnome/etc and if it was left open, developers 
could create their own constructs that could map to the target environment. 
(GNOMEish one for GNOME, KDEish one for KDE). So ya...I think your right on 
the money there.

As for the inheritance, I was thinking that there would be some methods that 
every FS class should have, but are more convenience methods and would 
pretty much just be wrappers around other class methods. It would be nice to 
not have to write this for every FS class, just inherit them from the 
parent. 


-- 
Narayan Newton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/summerofcode/attachments/20050605/bcf77d00/attachment.html