Quantcast

Kill KIO (was: Repositioning the KDE brand)

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Kill KIO (was: Repositioning the KDE brand)

nf2.email
On Thu, Jul 9, 2009 at 12:05 PM, Evgeny
Egorochkin<[hidden email]> wrote:
>
> So please be specific.

Ok...

I love KIO, but - please, please, please - throw it away!

It's a "proprietary" system just for a minority of applications. It's
an obstackle for getting third party applications like openoffice.org,
mozilla or Qt-only to use full fledged network transparent
file-management. It's an obstackle for running KDE applications on
Gnome or Gnome applications on KDE. It's not that exciting from design
and capabilites anymore (compared to other options). It's a dead dog.

Sorry for repeating this - or a similar statement - once a year. I
really don't want to damage KDE. Just the opposite.

Cheers,
Norbert
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Thiago Macieira
nf2 wrote:
>I love KIO, but - please, please, please - throw it away!

Will never happen.

--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Thiago Macieira
In reply to this post by nf2.email
nf2 wrote:
>It's a "proprietary" system just for a minority of applications. It's
>an obstackle for getting third party applications like openoffice.org,
>mozilla or Qt-only to use full fledged network transparent
>file-management. It's an obstackle for running KDE applications on
>Gnome or Gnome applications on KDE. It's not that exciting from design
>and capabilites anymore (compared to other options). It's a dead dog.

I also dispute the "minority of applications". If it's a minority, it's
still the largest minority group, with no other solution having a greater
stake.

KIO has existed for 9 years, its protocol has been stable. It's possible
to integrate with it using D-Bus. If other applications don't integrate
with it, it's because they don't want to.

Besides, there is no other solution. GIO/GVFS brings its own set of
dependencies and protocol. Between converting the KDE apps to use that, or
converting the other apps to use KIO, the amount of work is more or less
the same. So let them convert.

We were here first.

--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Evgeny Egorochkin
In reply to this post by nf2.email
On Friday 10 July 2009 16:12:05 nf2 wrote:

> On Thu, Jul 9, 2009 at 12:05 PM, Evgeny
>
> Egorochkin<[hidden email]> wrote:
> > So please be specific.
>
> Ok...
>
> I love KIO, but - please, please, please - throw it away!
>
> It's a "proprietary" system just for a minority of applications.

It's for applications that care to link to it. The question is how hard it is
to link with and use KIO?

> It's an obstackle for getting third party applications like openoffice.org,
> mozilla or Qt-only to use full fledged network transparent
> file-management.

But these developers need to link to a some lib anyway for this to happen.
FUSE itself doesn't automount random stuff. @#$% POSIX doesn't allow URLs in
regular system calls (that's where the biggest problem lies actually), while
still allows nontrivial stuff like symlinks. On top of it you must manage
passwords, proxies and jobs.

> It's an obstackle for running KDE applications on
> Gnome or Gnome applications on KDE.

Lack of a common interface is an obstacle, not KIO itself.

> It's not that exciting from design and capabilites anymore (compared to
other options). It's a dead dog.

Emotions and "rubbing it in" have already done everything they could. To
convince people you need an detailed review so that your proposal can be
investigated on merit. As you can remember attempts at GObject<->QMetaObject
interop, gnome stuff wasn't as nice as it was hyped, because people were
comparing KDE reality and GNOME marketing(and maybe future).

I don't pretend to have in-depth knowledge of both KIO and GIO so these are
pulled out^H^H^H^H^H just my observations...

AFAIK:
* KIO has a very nice Job support
* it supports much more than fetching http pages: media,pop3, bluetooth and
such kioslaves come to mind

The consequences of using a KIO->GIO bridge:
* We get to share 4 or so protocols such as http, ftp and smb.
* Instead of these KIOslaves we get to maintain a rather complex patchwork to
handle the brige itself, network preferences and passwords

In fact these protocols are either trivial to implement or are implemented
using a lib we don't maintain, so KIOSlave is just a wrapper, probably much
simpler one than KIO->GIO

If we drop KIO and go with GIO, we're going to be stuck with:
* Jobs
* non-trivial slaves
* GObject

So it seems we get lots of hassle with no real benefit.

However there's another option: drift towards a standard lib that's indeed
COMMON to the two desktops, port advantageous features/arch approaches(if they
exist) to KIO. EG at this moment KIO depends on kdelibs which is bad from
cross-desktop POV although in reality only a couple of header files seem to be
relevant.

Removing kdelibs dep, making an option to run outside of kded, making
interfaces friendly to GObject wrapping, there are lots of things we can do.
Also talking to gnome devs about enhancing "GIOSlave" or whatever it is called
API to satisfy our needs, while keeping daemon implementations desktop-
specific.

It's quite possible that we can achieve quite some code reuse and portability,
enhance both KIO and GIO and keep our BIC promises. But for this to happen
somebody must take time to analyze what/if/how it is to be done, and of course
do it if it ends up being feasible...

If you're up to it, you're welcome ;)

> Sorry for repeating this - or a similar statement - once a year. I
> really don't want to damage KDE. Just the opposite.


-- Evgeny
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Dario Freddi-2
In reply to this post by nf2.email
On Friday 10 July 2009 15:12:05 nf2 wrote:
> I love KIO, but - please, please, please - throw it away!

Thiago already answered. And love and throw it away are a bit of different
opinions, so I doubt they can coexist.

>
> It's a "proprietary" system just for a minority of applications.

Define "proprietary" and "minority of applications" please.

> It's
> an obstackle for getting third party applications like openoffice.org,
> mozilla or Qt-only to use full fledged network transparent
> file-management
> It's an obstackle for running KDE applications on
> Gnome or Gnome applications on KDE.

Just like $stack is an obstacle to applications not using it. It's the same
old story. You choose what to support, you live with this. If you want to
support everything, you create wrappers. That's what we do. I can say GIO has
the same problem to me. So what?

> It's not that exciting from design
> and capabilites anymore (compared to other options). It's a dead dog.

Questionable. What are the other options that work better and provide the same
level of integration and flexibility that KIO does?

>
> Sorry for repeating this - or a similar statement - once a year. I
> really don't want to damage KDE. Just the opposite.
>
> Cheers,
> Norbert

--
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Lukáš Tinkl
In reply to this post by nf2.email
Dne pátek 10. července 2009 15:12:05 nf2 napsal(a):
> Ok...
>
> I love KIO, but - please, please, please - throw it away!
>
> It's a "proprietary" system just for a minority of applications.

I stopped reading after these two sentences.

--
Lukáš Tinkl <[hidden email]>
Software Engineer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

kevin.krammer (Bugzilla)
In reply to this post by nf2.email
On Friday, 2009-07-10, nf2 wrote:
> On Thu, Jul 9, 2009 at 12:05 PM, Evgeny
>
> Egorochkin<[hidden email]> wrote:
> > So please be specific.
>
> Ok...
>
> I love KIO, but - please, please, please - throw it away!

Both this and the subject are rather poor ways of trying to get a useful
discussion going, which makes the whole posting look more like a flamebait
than anything else.

> It's a "proprietary" system just for a minority of applications. It's
> an obstackle for getting third party applications like openoffice.org,
> mozilla or Qt-only to use full fledged network transparent
> file-management.

It is unfortunate that other software producing communities have difficulties
using D-Bus and local sockets.
Unfortunately this is the same technology any other comparable solution uses,
e.g. GVFS, so that won't help them either.

Speaking of GVSF it might be possible to introduce a Qt (or even KDE) based
client library for GVFS, which could be used by applications along side KIO
and which could be used to implement GVFS mount daemons using KDE
technologies.

There are just a lot of use cases where KIO is dead easy to use and where the
benefits of GVFS (e.g. limiting number of connections per remote side) don't
matter that much.
However, there could still be use cases where using the explicit mount style
system would be benefitial.

It didn't help that the other thread mentioned GObject a lot, which lead to
mislead assumtions that GVFS would imply introducting such dependencies.
GVFS is, just like KIO, a service based approach of handling multiprotocol
I/O, thus allowing any technology stack being used on both sides of the
communication channels.

The application side for the KDE stack would therefore only consists of
already used components. Whether there is the need to implement certain
protocol handlers using our stack or whether those provided by others are
sufficient would most likely have to be evaluated on a case by case basis.

Cheers,
Kevin

--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Bugzilla from ggrabler@gmail.com
I think we should leave this topic to the guys developing KIO, GVFS and who want to collebrate on freedesktop.org. I think that's something the communities could work together, even when may be a huge effort for both. This could end up in a general low-level backend like the *kits or just some backend libraries to be used by KIO and GVFS to cooperate on dependencies, quality, release management and ressources.

For the rest ... I agree with other speakers before, the wording was extremely bad. It rather pushes to flamewars than constructive feedback and discussion.

Yours,
Georg Grabler (STiAT)

On Fri, Jul 10, 2009 at 6:01 PM, Kevin Krammer <[hidden email]> wrote:
On Friday, 2009-07-10, nf2 wrote:
> On Thu, Jul 9, 2009 at 12:05 PM, Evgeny
>
> Egorochkin<[hidden email]> wrote:
> > So please be specific.
>
> Ok...
>
> I love KIO, but - please, please, please - throw it away!

Both this and the subject are rather poor ways of trying to get a useful
discussion going, which makes the whole posting look more like a flamebait
than anything else.

> It's a "proprietary" system just for a minority of applications. It's
> an obstackle for getting third party applications like openoffice.org,
> mozilla or Qt-only to use full fledged network transparent
> file-management.

It is unfortunate that other software producing communities have difficulties
using D-Bus and local sockets.
Unfortunately this is the same technology any other comparable solution uses,
e.g. GVFS, so that won't help them either.

Speaking of GVSF it might be possible to introduce a Qt (or even KDE) based
client library for GVFS, which could be used by applications along side KIO
and which could be used to implement GVFS mount daemons using KDE
technologies.

There are just a lot of use cases where KIO is dead easy to use and where the
benefits of GVFS (e.g. limiting number of connections per remote side) don't
matter that much.
However, there could still be use cases where using the explicit mount style
system would be benefitial.

It didn't help that the other thread mentioned GObject a lot, which lead to
mislead assumtions that GVFS would imply introducting such dependencies.
GVFS is, just like KIO, a service based approach of handling multiprotocol
I/O, thus allowing any technology stack being used on both sides of the
communication channels.

The application side for the KDE stack would therefore only consists of
already used components. Whether there is the need to implement certain
protocol handlers using our stack or whether those provided by others are
sufficient would most likely have to be evaluated on a case by case basis.

Cheers,
Kevin

--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Cornelius Schumacher
In reply to this post by Thiago Macieira
On Friday 10 July 2009 16:31:50 Thiago Macieira wrote:
>
> KIO has existed for 9 years, its protocol has been stable. It's possible
> to integrate with it using D-Bus. If other applications don't integrate
> with it, it's because they don't want to.

Is it documented somewhere how to integrate with kio via D-Bus?

--
Cornelius Schumacher <[hidden email]>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Thiago Macieira
Cornelius Schumacher wrote:
>On Friday 10 July 2009 16:31:50 Thiago Macieira wrote:
>> KIO has existed for 9 years, its protocol has been stable. It's
>> possible to integrate with it using D-Bus. If other applications don't
>> integrate with it, it's because they don't want to.
>
>Is it documented somewhere how to integrate with kio via D-Bus?

No, I don't think so. You need to ask klauncher to start a slave for you,
then you communicate with that slave via standard QDataStream protocol.

I tried adding D-Bus support for kioslaves before the KDE 4 release, but
gave up because I wasn't seeing the point. The protocol isn't suitable for
the communications we need (synchronous, blocking) and I also didn't see
the value.

It was making our lives harder for no real benefit. If there's real want
for this, I can resurrect the project.

But don't make me waste my time if no one is going to use this.
--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Evgeny Egorochkin
On Sunday 12 July 2009 15:44:31 Thiago Macieira wrote:

> Cornelius Schumacher wrote:
> >On Friday 10 July 2009 16:31:50 Thiago Macieira wrote:
> >> KIO has existed for 9 years, its protocol has been stable. It's
> >> possible to integrate with it using D-Bus. If other applications don't
> >> integrate with it, it's because they don't want to.
> >
> >Is it documented somewhere how to integrate with kio via D-Bus?
>
> No, I don't think so. You need to ask klauncher to start a slave for you,
> then you communicate with that slave via standard QDataStream protocol.
>
> I tried adding D-Bus support for kioslaves before the KDE 4 release, but
> gave up because I wasn't seeing the point. The protocol isn't suitable for
> the communications we need (synchronous, blocking) and I also didn't see
> the value.
>
> It was making our lives harder for no real benefit. If there's real want
> for this, I can resurrect the project.
>
> But don't make me waste my time if no one is going to use this.

If there's no demand, it's not done. If it's not done, there's no demand ;)

To make KIO usable to non-kde apps, preferably it should be available as a
separate package with less dependencies(eg no kdelibs). Also it really makes
sense to discuss with with GIO people. Even if we don't share code, we might
at least share some of our interfaces which would be a first step towards a
shared(and useful) VFS.

Discussions with GIO people and analysis of what can/should be done indeed
takes quite some effort and it appeared to me there was a person interested in
doing this... but he's been silent for some time... maybe got scared of the
actual complexity of the task or angry KDE developers? ;)

-- Evgeny
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Thiago Macieira
Evgeny Egorochkin wrote:

>On Sunday 12 July 2009 15:44:31 Thiago Macieira wrote:
>> Cornelius Schumacher wrote:
>> >On Friday 10 July 2009 16:31:50 Thiago Macieira wrote:
>> >> KIO has existed for 9 years, its protocol has been stable. It's
>> >> possible to integrate with it using D-Bus. If other applications
>> >> don't integrate with it, it's because they don't want to.
>> >
>> >Is it documented somewhere how to integrate with kio via D-Bus?
>>
>> No, I don't think so. You need to ask klauncher to start a slave for
>> you, then you communicate with that slave via standard QDataStream
>> protocol.
>>
>> I tried adding D-Bus support for kioslaves before the KDE 4 release,
>> but gave up because I wasn't seeing the point. The protocol isn't
>> suitable for the communications we need (synchronous, blocking) and I
>> also didn't see the value.
>>
>> It was making our lives harder for no real benefit. If there's real
>> want for this, I can resurrect the project.
>>
>> But don't make me waste my time if no one is going to use this.
>
>If there's no demand, it's not done. If it's not done, there's no demand
> ;)
>
>To make KIO usable to non-kde apps, preferably it should be available as
> a separate package with less dependencies(eg no kdelibs).
No.

KIO can be a full D-Bus protocol in itself, without KDE dependencies. How
we implement it, it's besides the point. Others can implement it without
KDE dependencies. We will use them.

The KIO library is very intricately linked to kdecore and kdeui. There's
just no way to take it out.

> Also it
> really makes sense to discuss with with GIO people. Even if we don't
> share code, we might at least share some of our interfaces which would
> be a first step towards a shared(and useful) VFS.

Agreed.

>Discussions with GIO people and analysis of what can/should be done
> indeed takes quite some effort and it appeared to me there was a person
> interested in doing this... but he's been silent for some time... maybe
> got scared of the actual complexity of the task or angry KDE
> developers? ;)

The person interested in this is the one who started this thread: Norbert,
a.k.a. nf2.

--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Cornelius Schumacher
In reply to this post by Thiago Macieira
On Sunday 12 July 2009 14:44:31 Thiago Macieira wrote:
>
> I tried adding D-Bus support for kioslaves before the KDE 4 release, but
> gave up because I wasn't seeing the point. The protocol isn't suitable for
> the communications we need (synchronous, blocking) and I also didn't see
> the value.

What would be the best way of using kio from Qt-only applications? Would a
D-Bus API be useful for this? It's kind of sad that all the Qt-only apps miss
the excellent desktop integration kio provides, although they are technically
so close to KDE.

--
Cornelius Schumacher <[hidden email]>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Thiago Macieira
Cornelius Schumacher wrote:

>On Sunday 12 July 2009 14:44:31 Thiago Macieira wrote:
>> I tried adding D-Bus support for kioslaves before the KDE 4 release,
>> but gave up because I wasn't seeing the point. The protocol isn't
>> suitable for the communications we need (synchronous, blocking) and I
>> also didn't see the value.
>
>What would be the best way of using kio from Qt-only applications? Would
> a D-Bus API be useful for this? It's kind of sad that all the Qt-only
> apps miss the excellent desktop integration kio provides, although they
> are technically so close to KDE.
All they need is KIO::NetworkAccessManager.

But, yeah, I still have the idea of what kind of D-Bus API we could
implement.

The only problem is, like I said, that ioslaves expect a synchronous
*blocking* interface, whereas D-Bus requires an event loop. The way to
solve that problem is to use threads.

--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Harri Porten
In reply to this post by Cornelius Schumacher
On Sun, 12 Jul 2009, Cornelius Schumacher wrote:

> On Sunday 12 July 2009 14:44:31 Thiago Macieira wrote:
>>
>> I tried adding D-Bus support for kioslaves before the KDE 4 release, but
>> gave up because I wasn't seeing the point. The protocol isn't suitable for
>> the communications we need (synchronous, blocking) and I also didn't see
>> the value.
>
> What would be the best way of using kio from Qt-only applications? Would a
> D-Bus API be useful for this? It's kind of sad that all the Qt-only apps miss
> the excellent desktop integration kio provides, although they are technically
> so close to KDE.

What I find more sad is that a KDE dependency is always treated like
pestilence - even on KDE lists. People go out of their way to rewrite
things, dumb them down instead of simply linking against a library that is
already available. "Qt-only" is a misnomer anyway as e.g. QtGui links
against lots of other libraries already. If the feeling is that e.g. KIO
is too hard to distribute without pulling in all of kdelibs then more
modularization would be the way to go imo.

Harri.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Thiago Macieira
Harri Porten wrote:

>On Sun, 12 Jul 2009, Cornelius Schumacher wrote:
>> On Sunday 12 July 2009 14:44:31 Thiago Macieira wrote:
>>> I tried adding D-Bus support for kioslaves before the KDE 4 release,
>>> but gave up because I wasn't seeing the point. The protocol isn't
>>> suitable for the communications we need (synchronous, blocking) and I
>>> also didn't see the value.
>>
>> What would be the best way of using kio from Qt-only applications?
>> Would a D-Bus API be useful for this? It's kind of sad that all the
>> Qt-only apps miss the excellent desktop integration kio provides,
>> although they are technically so close to KDE.
>
>What I find more sad is that a KDE dependency is always treated like
>pestilence - even on KDE lists. People go out of their way to rewrite
>things, dumb them down instead of simply linking against a library that
> is already available. "Qt-only" is a misnomer anyway as e.g. QtGui
> links against lots of other libraries already. If the feeling is that
> e.g. KIO is too hard to distribute without pulling in all of kdelibs
> then more modularization would be the way to go imo.
QtGui in a KDE environment will load the oxygen plugin, which in turn
loads kdecore and kdeui.

So you're basically still linking to kdeui and kdecore.

--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

nf2.email
In reply to this post by Thiago Macieira
On Fri, Jul 10, 2009 at 4:31 PM, Thiago Macieira<[hidden email]> wrote:

> nf2 wrote:
>>It's a "proprietary" system just for a minority of applications. It's
>>an obstackle for getting third party applications like openoffice.org,
>>mozilla or Qt-only to use full fledged network transparent
>>file-management. It's an obstackle for running KDE applications on
>>Gnome or Gnome applications on KDE. It's not that exciting from design
>>and capabilites anymore (compared to other options). It's a dead dog.
>
> I also dispute the "minority of applications". If it's a minority, it's
> still the largest minority group, with no other solution having a greater
> stake.

Of course, but it's still a minority.

>
> KIO has existed for 9 years, its protocol has been stable. It's possible
> to integrate with it using D-Bus. If other applications don't integrate
> with it, it's because they don't want to.

I guess they would love to provide full featured file-management. It's
just too hard at the moment. Therefore if an application is not
targeting a particular DE, it will choose "local filesystem only".
Which is sad.

>
> Besides, there is no other solution. GIO/GVFS brings its own set of
> dependencies and protocol. Between converting the KDE apps to use that, or
> converting the other apps to use KIO, the amount of work is more or less
> the same. So let them convert.

I do understand that GIO/GVFS would be hard to swallow for KDE.
Just like the opposite. Any common solution trying to fix the problem
will bring in additional dependencies.

I'm not sure whether converting KDE apps would be that hard. Because
KIO as an abstraction layer has been so successful within the KDE
world (I said I love it - and I mean it), there would be no necessity to
migrate everything at once as long as the API stays intact.

"Let them convert": I also understand KDEs reluctance to adopt
something different. But that kind of depends on the perspective you
look
at it: GIO/GVFS could be seen as a competing technology (some people
even call it a "clone") - but also as a
next generation KIO.

However, the whole issue is not really a technical one: It's about
independence. Does KDE need to fully control and "own" the VFS
technology it's using? I understand that for someone who has put a lot
of energy into KIO recently, the answer certainly is *yes*. I guess -
for a lot of other people within the KDE community as well. Beeing "on
par" with Gnome in every layer of the platform, having own
implementations in the first place, resolving interoperability
problems by defining common standards, that's the traditional concept
of thinking how DEs are supposed to cooperate: Assuring a high level
of independence. Unfortionately a rather complex thing like
filemanagement can't be fixed without giving up lots of independence.

>
> We were here first.
>

True, but does it solve the problem?


Regards,

Norbert
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

Boudewijn Rempt-2
In reply to this post by Harri Porten
On Sunday 12 July 2009, Harri Porten wrote:

> What I find more sad is that a KDE dependency is always treated like
> pestilence - even on KDE lists. People go out of their way to rewrite
> things, dumb them down instead of simply linking against a library that is
> already available. "Qt-only" is a misnomer anyway as e.g. QtGui links
> against lots of other libraries already. If the feeling is that e.g. KIO
> is too hard to distribute without pulling in all of kdelibs then more
> modularization would be the way to go imo.

I definitely think that much more modularization is needed. Because the
libraries are intertwined instead of being like the teeth of a comb, separate,
independent and providing just one thing, you need most of the kdelibs which
makes it hard to cut down the size of your application, which is needed for
some platforms.

Plus, the need for things like dbus, knotify and other things are rather a
chore, especially on OSX, Windows or constrained platforms like Maemo. Those
make packaging harder. I can create an installer for a Qt-only application for
three platforms easily; making a self-contained package for a KDE application
is much harder.

For me, KDE as a development platform only really works when developing for a
Unix desktop environment, and when I want to have my applications available on
other platforms, I'll gladly trade down to Qt-only, losing some of the KDE
smarts in return for ease of deployment and less memory usage.

--
Boudewijn Rempt | http://www.valdyas.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

jos poortvliet-6
In reply to this post by nf2.email
On Sun, Jul 12, 2009 at 10:43 PM, nf2<[hidden email]> wrote:

> On Fri, Jul 10, 2009 at 4:31 PM, Thiago Macieira<[hidden email]> wrote:
>> nf2 wrote:
>>>It's a "proprietary" system just for a minority of applications. It's
>>>an obstackle for getting third party applications like openoffice.org,
>>>mozilla or Qt-only to use full fledged network transparent
>>>file-management. It's an obstackle for running KDE applications on
>>>Gnome or Gnome applications on KDE. It's not that exciting from design
>>>and capabilites anymore (compared to other options). It's a dead dog.
>>
>> I also dispute the "minority of applications". If it's a minority, it's
>> still the largest minority group, with no other solution having a greater
>> stake.
>
> Of course, but it's still a minority.

Sure, compared to Windows and Mac. On the Free Desktop it is a majority however.

>>
>> KIO has existed for 9 years, its protocol has been stable. It's possible
>> to integrate with it using D-Bus. If other applications don't integrate
>> with it, it's because they don't want to.
>
> I guess they would love to provide full featured file-management. It's
> just too hard at the moment. Therefore if an application is not
> targeting a particular DE, it will choose "local filesystem only".
> Which is sad.

Well, there clearly doesn't seem to be any demand for a cross-desktop
VFS system - as Thiago said, there has been a proven, stable, powerful
de-facto standard out there for 9 years. Yet the GVFS/GIO developers
chose to ignore that and in true NIH fashion develop something
completely new and incompattible (and it's not the first time such a
thing has happened).  So tell me why all KDE developers now should go
completely out of their way to throw away KIO in the spirit of
cross-desktop collaboration?

>>
>> Besides, there is no other solution. GIO/GVFS brings its own set of
>> dependencies and protocol. Between converting the KDE apps to use that, or
>> converting the other apps to use KIO, the amount of work is more or less
>> the same. So let them convert.
>
> I do understand that GIO/GVFS would be hard to swallow for KDE.
> Just like the opposite. Any common solution trying to fix the problem
> will bring in additional dependencies.

From what I understand from this discussion, they could implement KIO
in GTK, and they should have done that instead of writing something
new.

> I'm not sure whether converting KDE apps would be that hard. Because
> KIO as an abstraction layer has been so successful within the KDE
> world (I said I love it - and I mean it), there would be no necessity to
> migrate everything at once as long as the API stays intact.
>
> "Let them convert": I also understand KDEs reluctance to adopt
> something different. But that kind of depends on the perspective you
> look
> at it: GIO/GVFS could be seen as a competing technology (some people
> even call it a "clone") - but also as a
> next generation KIO.
>
> However, the whole issue is not really a technical one: It's about
> independence. Does KDE need to fully control and "own" the VFS
> technology it's using? I understand that for someone who has put a lot
> of energy into KIO recently, the answer certainly is *yes*. I guess -
> for a lot of other people within the KDE community as well. Beeing "on
> par" with Gnome in every layer of the platform, having own
> implementations in the first place, resolving interoperability
> problems by defining common standards, that's the traditional concept
> of thinking how DEs are supposed to cooperate: Assuring a high level
> of independence. Unfortionately a rather complex thing like
> filemanagement can't be fixed without giving up lots of independence.
>
>>
>> We were here first.
>>
>
> True, but does it solve the problem?
>

I'm not at home in the technical department, but I haven't seen any
strong technical arguments. Is the GIO/GVFS system clearly superior to
KIO, does it offer all the functionality and more with better
performance and stability? If that's the case I would guess there
wouldn't be so much resistance. If it sucks compared to KIO, what the
heck were you thinking even proposing it?

> Regards,
>
> Norbert
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kill KIO (was: Repositioning the KDE brand)

nf2.email
On Mon, Jul 13, 2009 at 10:59 AM, Jos Poortvliet<[hidden email]> wrote:
>
> I'm not at home in the technical department, but I haven't seen any
> strong technical arguments. Is the GIO/GVFS system clearly superior to
> KIO, does it offer all the functionality and more with better
> performance and stability? If that's the case I would guess there
> wouldn't be so much resistance. If it sucks compared to KIO, what the
> heck were you thinking even proposing it?
>

Let's describe the major differences in design first. It's about
connection sharing and stateless vs. statefull.

* In KIO the daemon processes exist on per client basis. For every
application working on a certain FTP server there will be at least one
ioslave instance and one FTP connection. Thus if you list an FTP
directory in dolphin and in kwrites filechooser, there will be two
ioslaves and two FTP connections. If the FTP server limits the number
of connections, you might hit that limit. It's not really controllable
by the user, how long a connection lives. That's a matter of waiting
for the ioslaves idle timeout. A kind of stateless design. You never
know if you are still connected.

* In GVFS, daemon processes (which are called "mount daemons") are
instantiated per remote resource. For instance a certain user@server.
Every application beeing interestet in the same remote resource will
talk to the same mount daemon. Therfore in most cases only a single
connection to the remote side is necessecary as long as there are no
concurrent calls. The deamon process will live until you "unmount" it.
You don't have to type the password again as long as you don't unmount
(The mount appears in the list of drives and as desktop icon, just
like a CD or a USB stick).

I would describe the design of GVFS as somehow similar to FUSE. The
only difference is that calls don't go through the POSIX API but
through D-Bus for the signaling and a custom p2p socket protocol for
the payload data. That kind of circumvents the limitations of POSIX in
FUSE (cancellation, detailed error messages,...). The management of
the mount daemons lives in a kind of "master daemon" which is started
via D-Bus. Applications talk to the "master daemon" first, to look up
or instantiate a certain mount daemon.

Threads and connection pooling: Depending on the protocol, calls can
be put on different threads in the mount daemon. This is necessary for
instance for FTP, which doesn't have atomic read or write operations.
An entire file transfer is a single FTP operation. If there is a
concurrent operation, another thread and connection is needed in the
mount deamon. For SMB that's not necessary AFAIK, because calls into
libsmbclient are atomic reads and writes.

* Local file management: The GVFS deamons are only needed for remote
filemanagement. Local filemanagement is done in-process, with threads
for async operations.

* The GIO client: I would describe the client API as more low-level
and fine-grained, probably harder to use than KIOs Jobs. It provides
both synchronous and asynchronous operations. Transfers are modelled
as streams, quite similar to Java's IO streams. For instance you can
wrap a GBufferedInputStream around a GInputStream. Seeking is also
supported. It also contains some other stuff, like Volume and Drive
management - everything you basically need for file-management. And
nice OO design too. In my opinion it would qualify as *the* basic API
for desktop file-mangement, but of course it should be wrapped by a
nice Qt/C++ API in KDE style.

* File attributes: GFileInfo has some similarities with UDSEntries,
but the properties have names and namespaces rather than integer
codes. When querying a FileInfo or listing a directory you can narrow
the query to certain property names (columns if you see it as a
database) or namespaces, in order to get a leaner and quicker
response.

* Quality of protocol handlers: That question i can't really answer.
Everything i tried (FTP, SFTP, SMB, Bluetooth), worked pretty well,
but GVFS developers probably can tell you more. I read somewhere
that's it's also gonna be used for HTTP in an Webkit based browser,
but i'm not sure. I also don't know how the HTTP handler works - if
it's a single multithreaded instance, or not...

However the devil is in the detatils. I can't tell if GIO/GVFS can
really provide everything KDE needs. I tried to investigate with
KIO-Giobridge for the most common protocols and that worked. But HTTP,
POP3 might be hairy.

Cheers,
Norbert
123
Loading...