[PATCH] Multi-Protocol IO-Slave
nf2 at scheinwelt.at
Sat Jan 12 17:30:05 GMT 2008
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
More information about the kde-core-devel