remove QtGui dependence of kdecore

[nf2]

Thiago Macieira wrote:
> Ralf Habacker wrote:
>   
>> While porting the kdecore/network code and kioslaves to windows, I
>> recognized that the class KIO connection implements network read/write
>> stuff already implemented in classes of kdecore/network. I understand
>> that KIO connection uses a command based read/write api which is
>> different from the related kdecore/network class and that this may be
>> the reason that this class could not be in kdecore but could they not
>> use the kdecore/network provided platform independent functions ?
>>     
>
> The KIO::Connection code predates the kdecore/network's predecessor... 
> It's been there from KDE 2.0 times. I introduced the predecessor in KDE 
> 2.2 and kdecore/network in 3.3.
>
> I had already planned on working on KIO::Connection. But my intention was 
> to overhaul it to transmit the commands over D-Bus (a private connection 
> or via bus), but keep the data transfers on a socket.
>
> In fact, in my history of over-engineering solutions to simple problems, I 
> even conceived an auto-negotiated multiple-transport solution: POSIX 
> message queues, System V shm, pipe/FIFO, Unix sockets, TCP sockets, D-Bus 
> P2P, D-Bus bus.
>
> I just never started working on that.
>
>   
>> It was discussed in this mailing list if it would be able to use threads
>> for kio-slaves. I think having a common base of a communication api (in
>> kdecore/network ?), would makes makes porting kio slaves to another
>> communication procotol like named pipe or shared memory easier.
>>     
>
> See above. Thankfully all of the command structure is already encapsulated 
> in KIO::Connection, so porting that to other communication mechanisms is 
> relatively easy.
>
> In special, I want to have a D-Bus-based command structure so that other, 
> non-KDE applications can talk to ioslaves easily (I'm thinking of Qt-only 
> apps).
>   

hi,

half a year ago i made a (very) rough proposal for standardizing a 
simple binary message protocol for io-slave socket communication. 
perhaps the protocol could be encapsulated in a little C-library or just 
be a written standard. by standardizing the application to slave 
protocol it would perhaps be possible to write plain C (or glib based) 
clients for KIO as well...

http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00999.html

the standard would define the message format, the "message flow" and how 
the message body for certain message types is serialized (for instance 
the fields of a directory entry)...

D-Bus would only be required to talk to the "VFS daemon", but not for 
direct application to slave connections... (which is the current KIO 
design AFAIK anyway)...

(there has been some discussion on the future of Gnome-VFS: 
http://thread.gmane.org/gmane.comp.gnome.vfs.general/2348/focus=2348 )