[summerofcode] FileSystemVirtualization - Ideas

Narayan Newton narayannewton at gmail.com
Sun Jun 5 06:51:32 CEST 2005


Hi all....


 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.

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. For example, lets call our master class MasterFS (there's that 
naming skill again) and lets say the uri "cvs://" signifies a call to a cvs 
file system. When a program tries to open a file with a uri in the "cvs://" 
style, it would use a table to find the right FileSystem object to pass the 
request to. It might not even use a table...maybe just a defined rule for 
how to go from the uri to the right FS object. (For example, "cvs://" might 
translate to CvsFileSystem and "svn://" to SvnFileSystem) The advantage here 
is obviously that the type of file system would make no difference to the 
program.


 Anyway...any thoughts on this? The second idea would definitely be more 
"complete" and seems more attractive to me, but I wanted to see if anyone 
here had any opinions.


-- 
Narayan Newton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/summerofcode/attachments/20050604/cbd88a1f/attachment.htm


More information about the summerofcode mailing list