[PATCH] Multi-Protocol IO-Slave

[nf2]

Kevin Ottens wrote:
> Le jeudi 10 janvier 2008, nf2 a écrit :
>   
>> This patch extends the KProtocolInfo system to accept a special
>> Multi-Protocol IO-Slave:
>> [...]
>>     
>
> The patch itself looks fine code wise. That said...
>
>   
>> [...]
>> This patch has no effect on the behavior of KIO unless a Multi-Protocol
>> IO-Slave .protocol file is installed. The aim of this patch is to allow
>> to develop and test bridging into a cross-desktop network-transparency
>> library without having to recompile or repackage kdelibs/kdebase
>> (without having to remove .protocol files of the original IO slaves).
>>     
>
> If that's the only purpose of this patch, I'm not exactly hot to commit it in 
> kdelibs. I think it should be maintained in a kdelibs branch you could use 
> for your experiments, or as a patch in the same directory than your ioslave.
>
> Because you're in a very early stage on this thing, if this patch gets 
> committed we'll have to support it for years... And what would happen if you 
> change your mind on the best way to achieve your goal? Or if finally this 
> ioslave doesn't deliver something usable? We'd be stuck with this code 
> exposing new API to maintain until KDE5.
>
> That's why I really believe it should stay close to your ioslave until the 
> situation on the matter is clearer.
>
>
>   

As the next release of Gnome (2.22 - planned to be released in March) 
will switch to GIO/GVFS, i think it's realistic to fully support 
GIO/GVFS in KDE 4.1. It should be quite stable and play all the major 
file-management protocols (sftp, ftp, smb, webdav) by then.

Sharing a cross-desktop network-transparency library will give 
applications (be it GTK/Gnome/3rd party apps on KDE or KDE apps on 
Gnome) a significant boost in terms of usability (As they are not locked 
out of desktop specific file-management systems anymore). A wider choice 
of applications adds a lot of value to the free desktops in general.

Therefore i believe making kio-giobridge work is an important short term 
goal. The necessary extensions - even if tagged as experimental - should 
at least be in the development branch of KDE. Testing - and contributing 
to - this bridge should be possible without having to patch and 
recompile kdelibs.

Cheers,

Norbert