Kill KIO (was: Repositioning the KDE brand)
phreedom.stdin at gmail.com
Fri Jul 17 03:51:15 BST 2009
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
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.
> 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
More information about the kde-core-devel