KDE is not an OS platform... (And neither is Gnome)

[nf2]

2009/10/29 Kevin Krammer <kevin.krammer at gmx.at>:
> On Wednesday, 2009-10-28, Alexander Neundorf wrote:
>> On Wednesday 28 October 2009, Aaron J. Seigo wrote:
>> > On October 28, 2009, Alexander Neundorf wrote:
>> > > Hmm, I don't really understand this email.
>> >
>> > the bits of context which are missing, and make it very hard to
>> > understand nf's email, are:
>> >
>> > * nf2 would like to have KIO use GIO; this is part of a general idea to
>> > make as much of KDE's "behind the scenes" infrastructure use things
>> > implemented in C on top of glib. the idea communicated to me on irc is
>> > that "glib and C is _the_ platform here, so we should use it instead of
>> > anything we make on our own".
>
> While Norbert and I disagree on the integration point in service oriented
> infrastructure, I think he didn't intend to convey that anything written in
> C/GLib is automatically the platform, instead that anything which wants to be
> part of the platform should be written in C/GLib.
>
> We obviously disagree on that as well, especially if the item in question is
> just one side of a service/client system.

Well - that's probably two lines of arguments which came too close
(it's my fault). It's not true that i want GIO here because i want to
push KDE into Glib+C just for the sake of it. I want the
"Free-Desktop-VFS", which has been discussed since many years.

1) Why Glib+C might make sense in this particular case: For a really
really basic technology like a VFS interface, which kind of sits just
one step above POSIX (only needed for the single reason that POSIX is
too poor), and which ideally should be linked by all available desktop
applications (directly, or indirectly via abstractions), it makes
sense to pick a framework and style which is as simplistic and low on
dependencies as possible. Just to get it really widely adopted. That's
one reason why i think GIO looks like a good deal. We should feel
lucky that we have it, because developing and consolidating such an
API takes years.

2) Getting towards a "lingua franca" for reusable software components
and sharing basic code as a "general idea"... That's probably more a
strategical and futuristic issue. But i would like to blank this out
here, because it's not very helpful indeed. I just wanted to mention
that our commercial competitors find it easier to make such decisions,
which IMHO gives them some advantage. However - I don't think all
"behind the scenes" infrastructure has to be written in C.

>
>> > * for various reasons, the approaches taken by nf2's code have been
>> > turned down by maintainers (such as Kevin Ottens as seen on
>> > http://reviewboard.kde.org/r/1951/ ... Kevin's reply there is pretty
>> > "short" because it's a discussion he and nf2 have already had in the past
>> > and i can empathize with Kevin's lack of desire to be forced into having
>> > that same conversation repeatedly)
>>
>> I didn't actually look at the patch in detail, but from the comments I had
>>  the impression that the purpose of the patch is to make the KDE places
>>  more flexible by adding pluggable backends ?
>> Doesn't sound that bad to me.
>
> I agree. Is the problem that this is a too high level place to support a
> different data source or the way the change is implemented?
>

To me it seems a pretty good place to dock. I tried two different
approaches before (Solid and having a new KStorage API). They just
brought in the GVFS network mounts, but didn't allow aligning the
entire places model. But when i got this last approach working,
something i didn't expect happened: Wow - i didn't realise that i was
just navigating around with Dolphin. I thought this was Nautilus. :-)

Regards,
Norbert