This article describes how to use GnomeVFS — a C library for accessing various file systems — to extend GNOME and develop your own extensions to the virtual file system. The article is centered around an imaginary example file system that lets you access an in-memory directory tree.
Extending GNOME with Virtual File Systems
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Why isn’t there a standard for this, that is desktop independant? Now this stuff is only for Gnome.
I know KDE has similar technology called KIO-slaves, but it would be nice if all desktop environments could settle on one standard VFS.
It would be nice if http://www.freedesktop.org provide such a standard, so both Gnome and KDE adopt it (not sure if there is already one).
There can NEVER be a shared implementation. Not because of practical reasons, but more because of community reasons.
GNOME would never use a kde implementation because it is written in C++.
KDE will never use a GNOME implementation because it is written with glib *gasp*.
This means that they can have shared standered in the sense that standerd uris will mean the same thing. I believe that the few that don’t work together (what are they? fish: & ssh:?) can, and will change a name to the same uri sooner or later
Why not an implementation in plain C. So everybody can write their freaking wrappers. Sometimes it looks like there are more wrappers than programs
A plain C implementation would be horrid, too – the worst of both worlds. Besides, KDE would never accept a C implementaion, glib or not – for them, it’s C++ or nothing, for all core components. (I’m not saying this is good or bad, but it does appear to be the truth.)
Looks like they are going to be forced to use Java.
Does not the world come around in circles, this sort of function table stuff is just how ONC-RPC and Xt (and I imagine just about every COM style system since). I thought Gnome had it’s own COM interface – is this all it is? But I suppose that it is at least linkable to from our languages unlike C++.
There’s no need for a common implentation. What’s needed is a standard specifying which are the basic URIs that a VFS system must implement (file:, zip:, etc.) and how to form such URIs.
I would like to see one sound daemon. Not kde with arts and gnome with esound. Jack looks nice.
> Besides, KDE would never accept a C implementaion, glib or
> not – for them, it’s C++ or nothing, for all core
> components.
Never.. never ever, after all kdelibs is not core component of KDE.. is it? kdelibs uses libxml2 aka gnome-xml which is btw. coded in plain C (without the ++).
> what are they? fish: & ssh:
Hmm, which would be a better standard URI for SSH(!) protocol.. fish:// or ssh:// *LOL*
Developer: Hmm, i’m going to implement SSH support to KIOslave. But what am i going to use as the URI.. s..ss.. fish! Yes, fish is very close to ssh i’ll use that =)
Great example of opensource project naming =) (names that i love BTW. but this is a bit odd.)
I would like to see one sound daemon. Not kde with arts and gnome with esound. Jack looks nice.
I personally think they’ll be pretty much useless once everybody moves to ALSA as it has software mixing capacibilities.
> But I suppose that it is at least linkable to from our
> languages unlike C++.
It is perfectly possible to link other languages from C++, I suggest you buy a decent book if you think it is not. You might also want to look at sip and koala if you want to see a tool that does it automatically.
I am really sick of correcting this piece of incorrect information.
Rich.
It is rather easy for C++ to link to languages other than C++. You just need the other languages to emit symbols using the C ABI, and then declare them as `extern “C”‘ from C++. This tends to be easy, as C is the lingua-franca of ABIs, and if you can’t call C, you’re not worth using. 🙂
The other way — linking to C++ code from other languages — is considerably harder. It *has* to be harder, as C++ support function/method overloading, which requires name mangling. Even better (read: worse), the name mangling used changes from compiler to compiler, or even between compiler versions! This is because there is no ABI standard for C++ (except on Itanium), so you CAN NOT expect to link C++ code generated from different compilers together.
So, if you want to link to C++ from a non-C++ language or from a different C++ compiler, what do you do? You write wrapper library that exports C equivalents for the C++ library features, compile the wrapper with the same C++ compiler as the original code, and link to this wrapper (using the C exports) from the other language.
You can use Swig (http://www.swig.org) to automate the wrapper generation process, but a C intermediate library is still typically necessary to use a C++ library from a non-C++ language.
If you know of any exceptions, I’d love to hear of them. The only way around the C API wrapper that I can think of would be to run “nm” on the C++ library, grab the mangled names, and somehow map the mangled names to methods in your higher-level language. Then cry out in anguish when the first C++ exception is generated…
In case of objevtive-c and java linking to c++ can be painless when you use the right compiler.
From Perl/Python and friends you always need to write a wrapper anyway, no matter whether its a C library or something else you want to package.
So I see no advantage in writing a library in C instead of C++.
The freedesktop.org guys have started discussing the standards possibility about a VFS:
https://listman.redhat.com/archives/xdg-list/2003-September/date.htm… (scroll down to 5th September)