Kill KIO (was: Repositioning the KDE brand)
nf2.email at gmail.com
Thu Jul 16 22:37:29 BST 2009
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.
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).
>> 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. Even if they way it happened has not been ideal, it
might still be suitable.
> 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
I believe that's rather a matter of just wanting it. If KDE wants it,
there will be ways to make it work.
The benefit would be a standard filemangement layer for the
More information about the kde-core-devel