kio and frameworks 5

[todd rme]

On Fri, May 11, 2012 at 10:33 PM, Casper Clemence <maninalift at gmail.com> wrote:
> I'm want to start a discussion, put an idea out there. I am also being
> pushy, on someone else's behalf.
>
> Although it may be a difficult discussion I think it would be a great shame
> to miss the opportunity to have it. I'm not trying to tell anyone to "do it
> this way".
>
> Please excuse me for saying "we" when I have not contributed to KDE as a
> developer, I tied myself in knots trying to write in the third person and
> gave up.
>
> Preamble over.
>
> The discussions is this "what part should libferris take in the refresh of
> KIO in KDE Frameworks 5?"
>
> Ben Martin really should be involved in any discussion of a redesign at the
> very least. He clearly has put a lot of work and thought into virtual
> filesystems and has created something quite unique.
>
> Libferris is an awesome piece of technology. It provides not just the
> traditional features of a VFS but a uniform method of access for
> applications and users to a large and expanding range of things. It has been
> demonstrated to work on maemo and as a Plasma DataEngine and has a web
> service interface. The rate at which Ben is able to turn out new
> capabilities for libferris also suggests it is well written and easy to
> develop.
>
> A uniform method of access for applications makes developing cool new stuff
> easier. A uniform method of access for users leads means a powerful tool to
> do what you want with your data, browsing a database in your file browser
> and dragging and dropping data around.
>
> So there are three points I want to suggest:
> (1) Speak to Ben about the possible developments of kio
> (2) learn from libferris
> (3) consider adopting libferris wholesale
>
> Possibly the biggest pain point with adopting libferris wholesale is that
> libferris indexes and KDE already has an indexer in strigi.
>
> But before the idea of adopting it wholesale into kdelibs is thrown out we
> should ask whether the difficulty of solving any issues we have with it
> really are greater than the difficulty of writing - and the advantage of
> those features libferris has which would never get written into kio.
>
> Libferris can already talk to soprano and Nepomuk, perhaps it should be
> considared whether allowing libferris to take over from strigi could
> actually be a good thing. Integration of the indexer into the VFS seems
> quite smart especially when the VFS knows how to read the structure of
> documents as well as index the text and metadata. I don't think that it is
> an easy question, whether or not it is worth it can only be answered by
> looking into it in technical detail, even trying it out.

One question I think might be worth asking is "what (if anything) is
kio missing?"  We have applications that do device or file access,
such as ark and k3b, that are not using kio slaves for that access.
Why not?  Is it just a lack of time, or is there something fundamental
in kio that makes this impossible, inefficient, or too difficult?  If
it is the latter, it would be good to fix it.  If it is the former,
then that implies kio does not provide something compelling enough for
them to want to switch.

The second question is, "will libferris help with this, or can it be
made to help?"

So I think the first question to ask is not, "should we switch to
libferris?", but "what is preventing kio from being used more in KDE
applications?"  If libferris is a solution, or at least part of a
solution, to the problem, then maybe we should consider switching.  If
not, then maybe another route might be better.

-Todd