A common VFS and a Common conf-system [Part II]

[Nicolai Haehnle]

On Tuesday 08 March 2005 18:01, Sean Middleditch wrote:
> On Tue, 2005-03-08 at 11:37 -0500, gtg990h at mail.gatech.edu wrote:
> > > They can patch GCC if they don't like any of those solutions.  Nothing
> > > about D-VFS will make it impossible for non-desktop apps to use.  It's
> > > just not something that a whole ton of time is being devoted to.
> > 
> > That's not a very good answer. Like it or not, something like an IDE is 
a
> > legitimate use-case here. Or something like a MySQL front-end, or a 
number of
> 
> It's the only answer feasible.  What other answer is there?  There's no
> other possible solution except FUSE, which is Linux-only, which means
> that it is completely unsuitable for our purposes.  If an application
> wants to use D-VFS, nothing stops it from doing so except apathy or
> ignorance.

I hope you do realize that what you're expecting isn't exactly realistic. 
And while FUSE is Linux-only, it would be foolish to reduce yourself to the 
lowest common denominator of all systems. With that said, I think it should 
be possible to find a way that doesn't affect the core design of D-VFS and 
still allows cooperation with legacy applications via FUSE.

What I'm proposing is a two-way translation part in the D-VFS client library 
that can turn "native OS paths" into "D-VFS URLs" and vice versa - just two 
functions "native_to_dvfs" and "dvfs_to_native".

native_to_dvfs will always succeed, by returning something like 
"file:///<the given path>", though some thought has to go into how the 
current working directory and the user's home directory may be resolved in 
the process.

dvfs_to_native must be allowed to fail, and the default implementation will 
only work for file:// URLs. However, on Linux, this function could check 
whether a working D-VFS-to-FUSE bridge exists and is mounted, and if so, 
return a path into the right FUSE mount.
It is important to make it *very* clear to application developers that they 
must not rely on dvfs_to_native to succeed.

This scheme has a number of advantages:
- It allows applications like IDEs to take advantage of FUSE without 
impacting installations and systems that have nothing like FUSE.
- It is relatively simple to implement.
- It can easily be extended to work on other OSs as more D-VFS-to-native 
bridges become available.
- Like it or not, desktop applications developers *will* come up with nasty 
hacks to bridge with legacy applications. By supplying these two functions, 
we can have a single hack in one place instead of many hacks in many 
places. This leads to overall cleaner code and fewer bugs.

cu,
Nicolai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050308/434f5454/attachment.pgp