KDE is not an OS platform... (And neither is Gnome)

[Kevin Krammer]

On Saturday, 2009-10-31, nf2 wrote:
> On Fri, Oct 30, 2009 at 10:23 PM, Kevin Krammer <kevin.krammer at gmx.at> 
wrote:

> > Yes, they do. GVFS mount daemon are separate processes, shared between
> > applications accessing the same protocol.
> 
> Actually in most cases they are launched per remote resource (like
> protocol://user@server). When I, for instance, connect to my own FTP
> server and ftp.kde.org, i can see two gvfsd-ftp processes running. But
> for HTTP there is only a single gvfsd-http...

Right, thanks for clarifying that.

> > The only thing missing is currently a Qt technology stack based client
> > library for GVFS, just like there is not GObject technology based on for
> > KIO slaves.
> 
> I guess you meant a pure Qt implementation, using QDBus...

For the D-Bus part, yes, and QLocalSocket for the data connection, etc.
So it will even work if GLib event loop integrations is not built into Qt or 
has been disabled at runtime.

> Yes, that sounds like an exciting undertaking for making this a true
> "service oriented
> infrastructure". And it's all D-Bus anyway, plus a binary socket
> protocol for GInputStream/GOutputStream...

Exactly.
Doesn't sound too hard to implement and would allow to directly map low level 
operations into the desired API style.
While that is not necessarily a huge benefit, I might make maintenance of that 
library easier.

> But probably not that essential for actually using it (at least in an
> ioslave) , as just linking current C-client doesn't look like a big
> burdon - it just uses some libraries from the GLib package plus
> libdbus-1 (it doesn't even require the libdbus-glib bindings).

I don't think the linking is a problem.
I am a bit concerned whether it would only work if Qt has GLib event loop 
integration available.
Generally it is usually a bad idea to layer an application developer facing 
API on top of another application developer facing API, because APIs designed 
to being used by application developer are usually targetting convenience, 
hiding internals, etc.

Like XLib making things which are not very nice for toolkit developers, so the 
need for a real base library like XCB came up.

For D-Bus it is even officially discouraged to build one binding on top of 
another.

> Technically I can only see a little problem, because GVFS needs some
> client side "intelligence" for mapping URIs to mount daemons. For some
> protocols this can't be done in a standard way (http, webdav and
> smb-shares), therefore there are specific GVfsUriMapper
> implementations. This code would have to be shared of course.

That code most likey does not have any "active" components so it should be 
easy to use them directly (probably only converting between C and C++ types).

Should also be possible to specify how to do the different mappings, just in 
case this gets interesting for developers staying away from system specific 
native libraries as much as possible (e.g. Java).

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091102/af415cbb/attachment.sig>