A common VFS and a Common conf-system [Part II]
prefect_ at gmx.net
Tue Mar 8 20:28:29 EET 2005
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
> > legitimate use-case here. Or something like a MySQL front-end, or a
> 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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050308/434f5454/attachment.pgp
More information about the xdg