[Portland] PortlandVFSProposal

[nf2]

Hi,

Bastian, Waldo wrote:

>>The only problem about KIO is that it has not been designed as common
>>infrastructure (in a toolkit and desktop independent way).
>>
>>Do you think it would make sense to rewrite KIO in C and to wrap a
>>synchronous and async API around the slave protocol (that it can serve
>>both the KIO::Jobs and the Gnome-VFS API.
>>    
>>
>
>It's easy to go from asynchronous to synchronous, that's what
>KIO::NetAccess does.
>  
>
KIO::NetAccess is quite different from the synchronous API in Gnome-VFS. 
It seems there are three API-flavours for VFS libraries:

A) real synchronous: Traditional blocking IO. open-read/write-close 
(chunks of data). no main loop integration. Useful for CLI-apps or for 
VFS access outside the GUI-thread (from a worker-thread for instance). 
Or perhaps for nesting protocol handlers.

B) async reading and writing chunks of data. Main loop integration and 
async callbacks.

C) pseudo synchronous: stay in a VFS-function until a task is completed 
(download, upload,...) and recurse the main-loop. In fact this is  just 
a convenience API around B.

Gnome-VFS provides A+B. KIO provides B+C (KIO::Jobs and KIO::NetAccess). 
I think to provide A with KIO you have to block on the slave-socket 
directly.

>>From an application point of view, to solve the "app doesn't know how to
>open weird URL" problem, it would be sufficient to have a KIO::NetAccess
>like API. I will have to take a look at Gnome-VFS to see how similar
>that one is. You could make a D-bus service to offer KIO::NetAccess like
>functionality which then delegates to either KIO or Gnome-VFS. That
>could be a useful partial solution.
>  
>
I wonder if such a "partial solution" would ever be trusted in or be 
very attractive. I wouldn't spend too much time on it...

- You have to make sure that either KDE or Gnome is installed  (or you 
need fallback-code in your application - what about other desktops?).
- It's the lowest common denominator with very limited functionality.
- It requires desktop adaptive file-dialogs (possible, but tricky to 
customize,...)
- Everything has to be written twice
- ...

I think solid desktop independent VFS infrastructure would be a lot more 
valuable. Please throw away Gnome-VFS and KIO as soon as possible. :-)

>Rewriting parts of KIO in C is certainly possible, the biggest technical
>hurdle is to document the current implicit assumptions in the code, in
>particular what the various KIO::Jobs expect from the protocol handlers.
>  
>
That sounds interesting. Could you please give some kind of 
introduction? Do you think it's possible to distinguish between
1) standardized behaviour/protocol handling for file-management 
(protocols like file:, ftp:, sftp:, smb:).
2) application specific behaviour/protocol handling (http:, imap:, 
pop:,...).

It would be interesting to find out which interfaces and protocols 
should be served by a common-vfs and which are KDE specific.

>I believe someone has actually once written a protocol handler
>(kioslave) for KIO in C already as a proof of concept.
>  
>
Cool. Where can i find it?

>The low level wire protocol of KIO is very much fixed (it's marshalling
>is Qt centric but that's documented so it's no problem to implement that
>under a different framework, or to switch to a different marshalling)
>  
>
Do you think D-BUS could be used? Or is it too high-level and + too much 
overhead with it's message-queues, message headers etc?
-> I would stay with something similar the current KIO wire protocol...

>the protocol handler at the other side could be using any framework it
>likes. You would want to offer framework bindings (similar to dbus
>language bindings) that make it easy to write a protocol handler using
>your preferred framework.
>  
>
I agree. Just the "standard" protocol-handlers should be (re)written in 
plain C (file, ftp, sftp, smb,...).

How to port the KIO-daemon? D-BUS?

Cheers,
Norbert