kio and frameworks 5

[Ben Martin]

On Tue, 2012-05-15 at 09:52 +0200, todd rme wrote:
...
> 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.

This is a great question! One of the things I think a VFS can do with
composite files like archives, mbox, xml, etc is offer additional
features above and beyond raw data access. For example, indexing (at the
file level) and change monitoring (ala inotify etc).

Many archives are indexed already, though for whatever reason tarballs
are still the de facto and suffer from linear access at many times. If
an index is created on first read (and maybe stored in soprano/EA) then
if the user wants file "foo", the VFS might be able to be read directly
from the index offset. As an implemented example, libferris does this
for mounting mbox, and stores the index itself in an extended attribute
of the mbox file.

An example with implementation in libferris of change tracking as a plus
is mounted XML. If one process changes the XML then another process
viewing that XML filesystem will see normal filesystem "events" telling
it about the change. This notification is at the subfile level, ie which
XML element has changed.


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

If you are mounting berkeley db or XML then it might help. libferris
doesn't have support for creating/burning to optical media.

> 
> 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.

I would also advocate at any level that the VFS and nepomuk/soprano
being good friends also helps many apps. Eg, "annotation" metadata being
available on anything that KIO can mount. Sorry about repeating this
point a few times here and there, but hopefully even if nothing else
makes it into the new KIO, this idea does :)

Going further, in ferris I have also implemented smushing so that
metadata bundles can be associated with one or more URLs. This allows
you to access the same file through many NFS mounts with uniform
metadata across all access paths to the file. Such things can also help
handle the case where files are moved/renamed on a file server without
the client machine's knowledge.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120516/164d27de/attachment.sig>