kio and frameworks 5

[Ben Martin]

I thought I would hihack a reply to the windows support response to this
message.

For me that hasn't ever really been a priority so there isn't much
support for it right now. The main issue would be the Linux file
monitoring used by the file:// module. Beyond that there are some POSIX
calls which might not be available on windows, for example
posix_fadvise() or copying files through madvise()ed mmaped locations.

I don't see any of these as show stoppers though. Just some chunks of
code which will need to be ifdefed or more cleanly replaced with
alternate modules and some posix glue APIs.

On Fri, 2012-05-11 at 21:33 +0100, Casper Clemence 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.
> 
> 
> -------
> I hope this was a useful conversation to start and I am not just being
> an ignorant user butting in on the development mailing list.
> 
> 
> Regards to you all
> Casper
> 
>