Kill KIO (was: Repositioning the KDE brand)

[Georg Grabler]

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 <kevin.krammer at gmx.at> wrote:

> On Friday, 2009-07-10, nf2 wrote:
> > On Thu, Jul 9, 2009 at 12:05 PM, Evgeny
> >
> > Egorochkin<phreedom.stdin at gmail.com> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090710/d18a559a/attachment.htm>