kio and frameworks 5

[Ben Martin]

On Tue, 2012-05-15 at 12:22 +0200, Aaron J. Seigo wrote:
> On Friday, May 11, 2012 21:33:35 Casper Clemence wrote:
> > 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
> 
> others have asked the "what does it do that KIO does not (or does poorly)" 
> question, and i'll add this to it:
> 
> is this about changing the application-facing API of KIO?

I would personally advocate for more metadata allowed to flow through
to/from apps from KIO.

> 
> the kioslave-facing API? (e.g. replacing current kio slaves with libferris as 
> the 'one implementation to bind them all')

I think perhaps this should be a separate issue in and of itself. If
both VFS can offer good interfaces then surely they can also play well
with each other, however folks decide to put the blocks together.

There are likely to be some blocks that libferris can provide which are
not offered by existing kio slaves so there is no duplication or
swapping of implementation for those. For example, the ability to mount
zoneminder as a filesystem.

> 
> the implementation of the various kioslaves (such as file, http, ...)?
> 
> does this only apply to a subset of kioslaves (e.g. file, but not http)?
> 
> iow, what is the scope of this discussion? :)
> 

IMHO it might be best to separate the discussion into what changes might
be seen as desirable in the application facing KIO interface, and a
separate item as to if/where/how libferris stuff plays a role in the
refresh. I don't want to tread on any toes here with implementations.
Starting with a general exchange of ideas at the API level might be
useful for all?

-------------- 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/608974e9/attachment.sig>