Kill KIO (was: Repositioning the KDE brand)

[Evgeny Egorochkin]

On Friday 17 July 2009 00:37:29 nf2 wrote:
> On Wed, Jul 15, 2009 at 7:04 PM, Thiago Macieira<thiago at kde.org> wrote:
> > Em Quarta-feira 15 Julho 2009, às 16:05:16, nf2 escreveu:
> >> On Wed, Jul 15, 2009 at 8:38 AM, Thiago Macieira<thiago at kde.org> wrote:
> >> > nf2 wrote:
> >> >>What kind of "platform" do you mean? A platform shared with other
> >> >> desktops?
> >> >
> >> > Yes.
> >> >
> >> >>Regarding the dependencies of GVFS you were talking about in an
> >> >>earlier mail: Which of those dependencies do you think would be
> >> >>problematic for KDE?
> >> >
> >> > The point is that there is no platform yet. I don't consider GVFS to
> >> > be part of such platform.
> >>
> >> Sure, but why?
> >
> > It doesn't exist. Do I have to explain why it doesn't? My point here is
> > that there was nothing to integrate with when KIO was written and there
> > continues to be nothing to integrate with now, replacing the
> > functionality.
>
> Well, for the VFS functionality there is something. :-)
>
> Regarding the more eccentric things KIO does (like HTTP, POP3) -
> moving them to a "shared platform" wouldn't be such a win. Quite often
> things like that are handled by different APIs than file-management.

But why such stupid restrictions? KIO is basically an API for manipulating 
file-like objects which can be (made to be) addressed by URLs. If it fits the 
api, why not use it?

IMAP4 can be treated much like a FTP server that only stores files of 
particular format(email). Yeah there may be an API that's better suited and 
exposes more functionality of POP3 and IMAP4, but this doesn't help an 
application that only understands KIO and doesn't really need anything other 
than fetch the file it's pointed at.

This makes KIO abstraction not only sufficient, but useful because the app would 
probably not implement several specialized APIs. Actually it's the same issue 
of using KIO vs libhttp, libftp etc. Or to illustrate my point, why people 
writing scripts use wget to fetch some page and not firefox?

if some other DE wants a subset of KIO slaves(eg because their software tends 
to use only a subset of KIO and some other API for other things), distro 
maintainers will be glad to separately package slaves into kio-essential and 
kio-alltherest.

You can replace GIO with KIO, but not vice versa.

Sharing 4 kio slave implementations with GIO is like wrapping a wrapper for a 
library when we already have a wrapper for the library. A lot more useful in 
this case is sharing of account passwords across different VFS implementations.

> My initial statement was not accurate of course. It was not about KIO
> in general as a technology of async IO helpers or as an API. Just the
> VFS part inside it (with VFS i mean the items that usually show up
> inside filemanagers and file-choosers).

An artifical distinction for the most part as explained above with a proposed 
solution for people who want to stick to this distinction no matter what.

> >> Which are the important arguments against choosing it as a platform
> >> technology? Is it dependencies, is it its technical design, the
> >> features, the quality or non technical reasons?
> >
> > How would I know? It wasn't designed to be a replacement for KIO (as far
> > as I know, KDE developers weren't invited to help the designing so that
> > it would be a suitable replacement). That's a direct opposite of D-Bus,
> > which was designed to replace DCOP, with input from KDE developers too.
>
> I don't really have the background knowledge here. I have heard
> contradictory things. And GIO/GVFS has not been developed in total
> secrecy either.

No KDE tech was ever developed in secrecy let alone total secrecy ;)

> Even if they way it happened has not been ideal,

It really doesn't matter. I can either ask for your input or anticipate what 
your input would be without asking. If I make the right guess(es), the product 
will be just as good.

> it
> might still be suitable.

Suitable for what? Apparently nothing had been done to make it useful for KDE. 
Otherwise a working GIO-KIO bridge with password storage and UI(file transfer 
status notifications) integration would be already available in playground 
since it appears that somebody wants to make it happen...

> > I think you're the one best qualified to give the technical reasons why.
> > And given your emails previously, it seemed to me that you don't believe
> > it to be a replacement for KIO either. (you listed many things that KIO
> > does and it doesn't)
>
> I believe that's rather a matter of just wanting it. If KDE wants it,
> there will be ways to make it work.

KDE wanting or not wanting it also depends on effort involved to make it work 
and benefits it brings.

> The benefit would be a standard filemangement layer for the
> freedesktop platform.

Standard doesn't mean good or useful unf.

Are GIO guys even interested in what you are doing? Do they care to read this 
thread?

-- Evgeny