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.
signature.asc
Description: This is a digitally signed message part
