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