[PATCH] Multi-Protocol IO-Slave

[nf2]

Thiago Macieira wrote:
> I do not think, however, that GIO is the answer. 

Who knows. I believe it's a great opportunity and at least we should try.

> For one thing, we've just 
> released KDE 4.0.0 with KIO support. That means we'll support it for the 
> next 5 years or so. For another, I don't see KDE developers writing 
> GIO-based slaves any time soon. They will write KIO-based ones because 
> they are simpler to write.
>   

Of course! Also, because KIO does a lot more than providing a framework 
for file-management (which is the primary target of GIO/GVFS). There 
seem to be lots of slaves which are application specific.

> Which brings me to two suggestions for future work:
> 1) a KDE/Qt-based implementation of the required parts of GIO, so that KDE 
> developers "feel at home" writing ioslaves.
>   

The easiest way to accomplish this would probably be a C++ wrapper for 
the mount daemon parts of GVFS. This could be Qt-based, but also Glibmm 
(I believe a C++ binding for the GIO-client is already under 
development). But - on the other hand - the number of protocol-handlers 
related to network-transparent file-management is relatively small (see 
below).

> 2) the reverse bridge, so that GIO/GVFS-based applications can use 
> kioslaves.
>
>   

I guess that would also be possible - as GIO has a design of pluggable 
backends. GIO is the interface, GVFS is loaded as implementation for 
UNIXes with dlopen() as an example. But it might require writing a 
KIO-client which fits into GIO, as it provides both synchronous and an 
async interfaces. Plugging a Qt based library into a Glib frontend 
sounds like an exciting experiment. This would really be 
hardcore-testing the shared main-loop (and everything related, like 
QtDBus living in the same process as GLib-DBus stuff).


Trying to clear up things a bit, i made a list of protocol-handlers 
installed by KDE:


==== Interesting for a shared VFS: ====

** Network transparent file-management **
(those are the important ones. delegating them to a shared VFS 
implementation would definitely be a win)

fish.protocol
ftp.protocol
sftp.protocol
ssh.protocol
nfs.protocol
smb.protocol
webdav.protocol
webdavs.protocol

remote.protocol (entry point for listing mounts, launching a mount 
helper, browsing smb://)


** local filemanagement: **
(delegating them to GIO/GVFS is not really required, the only reason 
might be to reduce the number of slave processes)

file.protocol (could be provided by the GIO bridge as well, just O_RDWR 
needs a native implementation)
floppy.protocol (GNOME just mounts floppies, no idea what's better - but 
could/should be aligned)
trash.protocol (could be delegated to GIO for consistency - but specs 
also work for this)


** archive browsing **
(there are no plans to provide them in GIO/GVFS, though it might work 
better than in KIO, because having stateful mount daemons should be an 
advantage here - particularly for write support)

ar.protocol
bzip.protocol
bzip2.protocol
tar.protocol
zip.protocol
gzip.protocol


==== Not relevant for a Shared-VFS (internal/app specific)====

** web-browsing: **
(can't be provided through GIO in the same quality. probably uses 
meta-data extensively, but i don't have a clue)

http.protocol
https.protocol

** local filemanagement, but internal **

thumbnail.protocol

** Desktop info/management - Konqueror specific AFAIK **

about.protocol
applications.protocol
help.protocol
info.protocol
ghelp.protocol
programs.protocol
fonts.protocol
settings.protocol
man.protocol

** Network, but application internal **

imap4.protocol
imaps.protocol
pop3.protocol
pop3s.protocol
ldap.protocol
ldaps.protocol
kmailservice.protocol
mbox.protocol
nntp.protocol
nntps.protocol
smtp.protocol
smtps.protocol
rtsp.protocol
rtspt.protocol
rtspu.protocol
sieve.protocol
rlogin.protocol
finger.protocol
telnet.protocol
mms.protocol
mmst.protocol
mmsu.protocol

** Don't know **

metainfo.protocol
pnm.protocol
cgi.protocol
data.protocol


Norbert