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

[nf2.email]

I'm writing this, because my patch to allow plugging a different model
into KFilePlaces got rejected, and i'm trying to understand why.

As a reminder: This screenshot should explain what i'm trying to
achieve: http://reviewboard.kde.org/r/1951/s/238/

I thought that i was solving a problem, but obviously a lot of people
don't see that as a problem. I thought that moving towards a coherent
file-management experience should be something that everybody wants.
But - and i must say i'm quite astonished - it's not regarded as
important at all.


This misunderstanding must have something to do with 180 degree
different views on two issues:

1) What defines an "OS platform"?

2) The importance of the application base for the success of such a platform.


In my next mail i would like to discuss possible solutions for "the
problem" (which perhaps isn't a problem),... why i think that my
proposal might be the "cheapest" way for making progress here (in
terms of cost/benefit)... why it's important to start with this
"early"... and so on...

Regards
Norbert

[Alexander Neundorf]

On Wednesday 28 October 2009, nf2 wrote:

> I'm writing this, because my patch to allow plugging a different model
> into KFilePlaces got rejected, and i'm trying to understand why.
>
> As a reminder: This screenshot should explain what i'm trying to
> achieve: http://reviewboard.kde.org/r/1951/s/238/
>
> I thought that i was solving a problem, but obviously a lot of people
> don't see that as a problem. I thought that moving towards a coherent
> file-management experience should be something that everybody wants.
> But - and i must say i'm quite astonished - it's not regarded as
> important at all.
>
>
> This misunderstanding must have something to do with 180 degree
> different views on two issues:
>
> 1) What defines an "OS platform"?
>
> 2) The importance of the application base for the success of such a
> platform.

Hmm, I don't really understand this email.

From looking at the reviewboard link, the patch is about optionally using the
places/bookmarks from gnome/gtk in KDE ?
Is there a freedesktop spec how these should be stored/accessed ?

Alex

[nf2.email]

On Wed, Oct 28, 2009 at 7:13 PM, Alexander Neundorf <neundorf@...> wrote:

> On Wednesday 28 October 2009, nf2 wrote:
>> I'm writing this, because my patch to allow plugging a different model
>> into KFilePlaces got rejected, and i'm trying to understand why.
>>
>> As a reminder: This screenshot should explain what i'm trying to
>> achieve: http://reviewboard.kde.org/r/1951/s/238/
>>
>> I thought that i was solving a problem, but obviously a lot of people
>> don't see that as a problem. I thought that moving towards a coherent
>> file-management experience should be something that everybody wants.
>> But - and i must say i'm quite astonished - it's not regarded as
>> important at all.
>>
>>
>> This misunderstanding must have something to do with 180 degree
>> different views on two issues:
>>
>> 1) What defines an "OS platform"?
>>
>> 2) The importance of the application base for the success of such a
>> platform.
>
>
> Hmm, I don't really understand this email.
>
> From looking at the reviewboard link, the patch is about optionally using the
> places/bookmarks from gnome/gtk in KDE ?

I wanted to demonstrate that a coherent file-management experience
would be fairly easy to achieve. Basically its just requires aligning
the places model and sharing the VFS implementation. This is what the
screenshot shows: An alternate KFilePlacesModel implementation in
combination with the Kio-Giobridge. And this is not a mockup.

The Kio-Giobridge can be enabled by installing different *.protocol
files. But for the places-panel i need the permission for adding a
plugin-interface behind KFileplacesModel.


> Is there a freedesktop spec how these should be stored/accessed ?
>

For bookmarks, yes. But it hasn't been implemented by Gnome yet (there
is a bug). Therefore the model you can see is using the
~/.gtk-bookmarks as a workaround.

Norbert

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".

* this has been discussed at great lengths a few times on irc and on mailing
lists (inc this one); the discussions have included nf2, maintainers of the
software in question and others with interests in these technologies

* nf2 has indeed done the "right thing" in that he's actually written code to
match his ideas; actually writing code is really more than many others can
say, and i do respect that quite a bit about nf2 and his ideas on these
matters

* 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)

it's one of those unfortunate circumstances where someone has written code
that doesn't mesh with the upstream project maintainer's goals. i do think nf2
has all the best of intentions and certainly has put in good amounts of effort
(nf2 is also very pleasant to work with, i might add :). the maintainers of
the code he is offering these specific patches to simply disagree on the
points at hand. so i don't think there is any bad happening here, just a
disagreement of opinion. thankfully we have maintainers to offer resolution
instead of things trailing on forever and the "last person speaking wins"
being the way we develop our software.

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

[Alexander Neundorf]

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".
>
> * this has been discussed at great lengths a few times on irc and on
> mailing lists (inc this one); the discussions have included nf2,
> maintainers of the software in question and others with interests in these
> technologies
>
> * nf2 has indeed done the "right thing" in that he's actually written code
> to match his ideas; actually writing code is really more than many others
> can say, and i do respect that quite a bit about nf2 and his ideas on these
> matters

That much I knew, just for the specific mail it wasn't clear what exactly he
meant.

> * 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.

> it's one of those unfortunate circumstances where someone has written code
> that doesn't mesh with the upstream project maintainer's goals. i do think
> nf2 has all the best of intentions and certainly has put in good amounts of
> effort (nf2 is also very pleasant to work with, i might add :). the

And we met at Akademy :-)

Alex

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.

> > * 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?

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

On Thursday 29 October 2009 13:14:46 Kevin Krammer wrote:
> 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?

While I respect the effort, my problem with it is that it adds an IMO
unnecessary extra layer of abstraction, adding to the burden of maintainers
who are already spread thin in this area of kdelibs.

Will

[Richard Dale-5]

On Thursday 29 October 2009 03:17:27 pm Will Stephenson wrote:
> On Thursday 29 October 2009 13:14:46 Kevin Krammer wrote:
> > 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?
>
> While I respect the effort, my problem with it is that it adds an IMO
> unnecessary extra layer of abstraction, adding to the burden of maintainers
> who are already spread thin in this area of kdelibs.
I don't have much of an opinion about the technical reasons for why GIO/KIO
integration might be a good idea or not.

But after meeting Norbert at the 2008 Akademy, he did inspire me to start on a
Gobject-Introspection/QMetaObject bridge project. I haven't had time to make
any progress on it recently as there are other more important language
bindings projects that I need to work on. Also it isn't quite as much fun to
work on, to be honest as a Qt/KDE only project, and the kind of thing someone
might do it sponsored perhaps.

I think DBus has proved really useful for integrating KDE and Gnome
technologies, but efforts like Norbert's or mine could be very useful in other
areas where we need to do some integration of libs within the same process and
DBus wouldn't be suitable. So I really think it is possible to improve on
existing ad hoc efforts to bridge between the GObject and QObject worlds with
bindings.

-- Richard

[nf2.email]

2009/10/29 Kevin Krammer <kevin.krammer@...>:

> 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

[nf2.email]

On Thu, Oct 29, 2009 at 4:17 PM, Will Stephenson <wstephenson@...> wrote:
> On Thursday 29 October 2009 13:14:46 Kevin Krammer wrote:
>> 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?
>
> While I respect the effort, my problem with it is that it adds an IMO
> unnecessary extra layer of abstraction, adding to the burden of maintainers
> who are already spread thin in this area of kdelibs.
>

Yes, i'm aware of both problems...

1) The extra layer of abstraction seems to be the only way to make
progress without breaking up KIO as an important technology for KDE.
Therefore i'm just delegating a bunch of protocols. And as KIO can
abstract libsmbclient, libssh or POSIX, it can certainly adopt another
VFS.

2) The impact on maintainability - i guess that's hard to predict. It
might as well have a trade-off, as a lot of work would be "outsourced"
to Gnome developers. And that technologies grow better with the number
of participants, that's a kind of  credo of FOSS...

However the biggest problem is of course, that my proposal is touching
the spirit of the KDE project: The desire for independence and
individuality...

Norbert

I'm still not sure if I should post this as I'm incompetent on KIO and
on GVFS, but precisely, perhaps it is useful that i mention why i
believe that this debate needs to be reframed as the solution, in my
humble opinion, lies far beyond KIO and GVFS.

The problem, if you ask me, is that there is a whole world of software
out there that has no interest in using either KIO or GVFS, and will
only use the native OS's VFS. Thus, a KIO-GVFS integration doesn't do
much to unify the VFS systems used across all the programs that run on
any of our machines.

Here's my proposal to unify KIO, GVFS, and the native OS VFS when
possible, while keeping the existing features when that is not
possible, without requiring one party to use the other's
infrastructure, and all transparently to applications.

***

A. First let's work under the simplistic assumption that all OS's that
we need to support have a native VFS that is good enough to allow
mounting KIO and GVFS into them.

1) Make sure that both KIO and GVFS can be mounted into the OS's native VFS.
2) Make it so that KIO and GVFS agree on a filesystem layout (a "name
mangling" if you want) so that the same filename can be used
regardless of the choice of KIO or GVFS. By a "name mangling" i mean a
translation from addresses like "sftp://user@server/path" to addresses
like "/mountpoint/ssh/user/server/path".
3) Reimplement the KIO and GFVS client libraries as just accessing
this mount point, using this name mangling, so that there's no API
change at all for KDE and GNOME apps.

Thus at this point the "Linux desktop" has a universal VFS accessible
as part of the native VFS by any program without any dependency, and
that can be transparently implemented either by KIO or by GVFS (each
disto would choose according to own preference), that should be
transparent to the user.

***

B. I dont actually know if that idea of mounting KIO/GVFS can work on
all OS's that we need to support. Here is an idea of what to do if
some OS can't do that:

We could still do A. with only this little difference: the KIO and
GVFS client libraries could, on these particular platforms, directly
access respectively KIO and GVFS libraries. Thus on these platforms,
nothing would change from today's situation, there would be no
KIO-GVFS integration, but that wouldn't be a big deal. (KDE-Gnome
integration doesnt matter that much on e.g. Windows, if we could have
it on linux we'd be happy already)

Thanks for reading,
Benoit

2009/10/29 nf2 <nf2.email@...>:

> On Thu, Oct 29, 2009 at 4:17 PM, Will Stephenson <wstephenson@...> wrote:
>> On Thursday 29 October 2009 13:14:46 Kevin Krammer wrote:
>>> 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?
>>
>> While I respect the effort, my problem with it is that it adds an IMO
>> unnecessary extra layer of abstraction, adding to the burden of maintainers
>> who are already spread thin in this area of kdelibs.
>>
>
> Yes, i'm aware of both problems...
>
> 1) The extra layer of abstraction seems to be the only way to make
> progress without breaking up KIO as an important technology for KDE.
> Therefore i'm just delegating a bunch of protocols. And as KIO can
> abstract libsmbclient, libssh or POSIX, it can certainly adopt another
> VFS.
>
> 2) The impact on maintainability - i guess that's hard to predict. It
> might as well have a trade-off, as a lot of work would be "outsourced"
> to Gnome developers. And that technologies grow better with the number
> of participants, that's a kind of  credo of FOSS...
>
> However the biggest problem is of course, that my proposal is touching
> the spirit of the KDE project: The desire for independence and
> individuality...
>
> Norbert
>

ah and one more thing.

I can sense responses about "the kernel's VFS doesn't support this or
that important feature" coming soon ;) As in this blog post about GVFS
and FUSE (which also shows that, predictibly, people already had the
same idea that i was proposing):
http://blog.fubar.dk/?p=104

The answer is that, if really current kernels lack a particular
feature, then that's a perfect occasion to go talk to kernel devs!
Don't I seem to remember that recently (at GCDS?) one of them asked
you guys if you had feature requests? And as I said in previous
e-mail, on OSes where we can't communicate with kernel devs, just keep
the statu quo.

ok now i'm really getting back to stuff where i can be useful : that's
NOT that ;)
Benoit

2009/10/30 Benoit Jacob <jacob.benoit.1@...>:

> I'm still not sure if I should post this as I'm incompetent on KIO and
> on GVFS, but precisely, perhaps it is useful that i mention why i
> believe that this debate needs to be reframed as the solution, in my
> humble opinion, lies far beyond KIO and GVFS.
>
> The problem, if you ask me, is that there is a whole world of software
> out there that has no interest in using either KIO or GVFS, and will
> only use the native OS's VFS. Thus, a KIO-GVFS integration doesn't do
> much to unify the VFS systems used across all the programs that run on
> any of our machines.
>
> Here's my proposal to unify KIO, GVFS, and the native OS VFS when
> possible, while keeping the existing features when that is not
> possible, without requiring one party to use the other's
> infrastructure, and all transparently to applications.
>
> ***
>
> A. First let's work under the simplistic assumption that all OS's that
> we need to support have a native VFS that is good enough to allow
> mounting KIO and GVFS into them.
>
> 1) Make sure that both KIO and GVFS can be mounted into the OS's native VFS.
> 2) Make it so that KIO and GVFS agree on a filesystem layout (a "name
> mangling" if you want) so that the same filename can be used
> regardless of the choice of KIO or GVFS. By a "name mangling" i mean a
> translation from addresses like "sftp://user@server/path" to addresses
> like "/mountpoint/ssh/user/server/path".
> 3) Reimplement the KIO and GFVS client libraries as just accessing
> this mount point, using this name mangling, so that there's no API
> change at all for KDE and GNOME apps.
>
> Thus at this point the "Linux desktop" has a universal VFS accessible
> as part of the native VFS by any program without any dependency, and
> that can be transparently implemented either by KIO or by GVFS (each
> disto would choose according to own preference), that should be
> transparent to the user.
>
> ***
>
> B. I dont actually know if that idea of mounting KIO/GVFS can work on
> all OS's that we need to support. Here is an idea of what to do if
> some OS can't do that:
>
> We could still do A. with only this little difference: the KIO and
> GVFS client libraries could, on these particular platforms, directly
> access respectively KIO and GVFS libraries. Thus on these platforms,
> nothing would change from today's situation, there would be no
> KIO-GVFS integration, but that wouldn't be a big deal. (KDE-Gnome
> integration doesnt matter that much on e.g. Windows, if we could have
> it on linux we'd be happy already)
>
> Thanks for reading,
> Benoit
>
> 2009/10/29 nf2 <nf2.email@...>:
>> On Thu, Oct 29, 2009 at 4:17 PM, Will Stephenson <wstephenson@...> wrote:
>>> On Thursday 29 October 2009 13:14:46 Kevin Krammer wrote:
>>>> 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?
>>>
>>> While I respect the effort, my problem with it is that it adds an IMO
>>> unnecessary extra layer of abstraction, adding to the burden of maintainers
>>> who are already spread thin in this area of kdelibs.
>>>
>>
>> Yes, i'm aware of both problems...
>>
>> 1) The extra layer of abstraction seems to be the only way to make
>> progress without breaking up KIO as an important technology for KDE.
>> Therefore i'm just delegating a bunch of protocols. And as KIO can
>> abstract libsmbclient, libssh or POSIX, it can certainly adopt another
>> VFS.
>>
>> 2) The impact on maintainability - i guess that's hard to predict. It
>> might as well have a trade-off, as a lot of work would be "outsourced"
>> to Gnome developers. And that technologies grow better with the number
>> of participants, that's a kind of  credo of FOSS...
>>
>> However the biggest problem is of course, that my proposal is touching
>> the spirit of the KDE project: The desire for independence and
>> individuality...
>>
>> Norbert
>>
>

On Friday 30 October 2009, Benoit Jacob wrote:
> 1) Make sure that both KIO and GVFS can be mounted into the OS's native
>  VFS. 2) Make it so that KIO and GVFS agree on a filesystem layout (a "name
>  mangling" if you want) so that the same filename can be used
> regardless of the choice of KIO or GVFS. By a "name mangling" i mean a
> translation from addresses like "sftp://user@server/path" to addresses
> like "/mountpoint/ssh/user/server/path".

Please keep in mind the difference between sync and async APIs.

You download a file over FTP. KIO is async: the application remains responsive,
you get a progress dialog. The "native VFS" is most of the time used in a
blocking way. fopen,fwrite,fclose. Which means the application freezes until
the FTP server sends the whole data. Not good.
A remote filesystem is NOT like the local filesystem.

Anyone who has ever had an NFS mount to a host that goes offline will certainly
see what I'm talking about (the shell being blocked for 5 minutes after each
command; GUI apps freezing for a very long time when trying to load/save/list
a directory...).

"KDE is not an OS platform"? If that means KDE doesn't provide kernel
filesystems for remote directories, I would say that's rather good.

--
David Faure, faure@..., http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

2009/10/30 David Faure <faure@...>:

> On Friday 30 October 2009, Benoit Jacob wrote:
>> 1) Make sure that both KIO and GVFS can be mounted into the OS's native
>>  VFS. 2) Make it so that KIO and GVFS agree on a filesystem layout (a "name
>>  mangling" if you want) so that the same filename can be used
>> regardless of the choice of KIO or GVFS. By a "name mangling" i mean a
>> translation from addresses like "sftp://user@server/path" to addresses
>> like "/mountpoint/ssh/user/server/path".
>
> Please keep in mind the difference between sync and async APIs.
>
> You download a file over FTP. KIO is async: the application remains responsive,
> you get a progress dialog. The "native VFS" is most of the time used in a
> blocking way. fopen,fwrite,fclose.

Thanks, I was missing this part (that the problem lies in the way that
applications use it).

Benoit

2009/10/30 Benoit Jacob <jacob.benoit.1@...>:

> 2009/10/30 David Faure <faure@...>:
>> On Friday 30 October 2009, Benoit Jacob wrote:
>>> 1) Make sure that both KIO and GVFS can be mounted into the OS's native
>>>  VFS. 2) Make it so that KIO and GVFS agree on a filesystem layout (a "name
>>>  mangling" if you want) so that the same filename can be used
>>> regardless of the choice of KIO or GVFS. By a "name mangling" i mean a
>>> translation from addresses like "sftp://user@server/path" to addresses
>>> like "/mountpoint/ssh/user/server/path".
>>
>> Please keep in mind the difference between sync and async APIs.
>>
>> You download a file over FTP. KIO is async: the application remains responsive,
>> you get a progress dialog. The "native VFS" is most of the time used in a
>> blocking way. fopen,fwrite,fclose.
>
> Thanks, I was missing this part (that the problem lies in the way that
> applications use it).

(sorry, i hit "send" a bit too fast)

But Linux 2.6 has an async I/O API already,
http://www.ibm.com/developerworks/linux/library/l-async/

Of course I understand that this wasn't available when KIO was designed!

You make a good point that apps would need to be adapted to do async
I/O but that's not KDE's fault ;)

I just would like to understand if there's a real reason anymore for
not letting KIO/GVFS go through the native VFS on Linux (and perhaps
other *nix). Again, on other exotic platforms, the statu quo seems
good enough.

Benoit

[nf2.email]

On Fri, Oct 30, 2009 at 12:40 PM, Benoit Jacob <jacob.benoit.1@...> wrote:

> ah and one more thing.
>
> I can sense responses about "the kernel's VFS doesn't support this or
> that important feature" coming soon ;) As in this blog post about GVFS
> and FUSE (which also shows that, predictibly, people already had the
> same idea that i was proposing):
> http://blog.fubar.dk/?p=104
>
> The answer is that, if really current kernels lack a particular
> feature, then that's a perfect occasion to go talk to kernel devs!
> Don't I seem to remember that recently (at GCDS?) one of them asked
> you guys if you had feature requests? And as I said in previous
> e-mail, on OSes where we can't communicate with kernel devs, just keep
> the statu quo.
>

I think it definitely makes sense to work on the ideal solution.

But there is this saying that the best solution is the enimy of the
good solution. And I rather prefer having the good solution tomorrow,
instead of just waiting for the "best" solution another five years.

While it's definitely a nice feature (another point why KDE should
adopt GVFS), there is a reaon why GVFS just provides FUSE as a
secondary channel. For instance FTP can't be mapped into the expected
POSIX behavior properly, therefore GVFS just mapps FTP read-only.

Regards,
Norbert

2009/10/30 nf2 <nf2.email@...>:

> On Fri, Oct 30, 2009 at 12:40 PM, Benoit Jacob <jacob.benoit.1@...> wrote:
>> ah and one more thing.
>>
>> I can sense responses about "the kernel's VFS doesn't support this or
>> that important feature" coming soon ;) As in this blog post about GVFS
>> and FUSE (which also shows that, predictibly, people already had the
>> same idea that i was proposing):
>> http://blog.fubar.dk/?p=104
>>
>> The answer is that, if really current kernels lack a particular
>> feature, then that's a perfect occasion to go talk to kernel devs!
>> Don't I seem to remember that recently (at GCDS?) one of them asked
>> you guys if you had feature requests? And as I said in previous
>> e-mail, on OSes where we can't communicate with kernel devs, just keep
>> the statu quo.
>>
>
> I think it definitely makes sense to work on the ideal solution.
>
> But there is this saying that the best solution is the enimy of the
> good solution. And I rather prefer having the good solution tomorrow,
> instead of just waiting for the "best" solution another five years.
>
> While it's definitely a nice feature (another point why KDE should
> adopt GVFS), there is a reaon why GVFS just provides FUSE as a
> secondary channel. For instance FTP can't be mapped into the expected
> POSIX behavior properly, therefore GVFS just mapps FTP read-only.

Ah OK. That sounds like a more fundamental argument why my proposal
won't work in the short-term, and why it would require kernel-level
changes that will take a long time to happen.

Benoit

On October 30, 2009, Benoit Jacob wrote:
> Ah OK. That sounds like a more fundamental argument why my proposal
> won't work in the short-term, and why it would require kernel-level
> changes that will take a long time to happen.

and for us to decide that newer linux releases are the only kernels we care
about. there are many other OSes we also support out there.

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

On Friday 30 October 2009 12:20:49 Benoit Jacob wrote:
> I just would like to understand if there's a real reason anymore for
> not letting KIO/GVFS go through the native VFS on Linux (and perhaps
> other *nix). Again, on other exotic platforms, the statu quo seems
> good enough.

There's no reason we can't (just modify the kioslave for #if Q_OS_FOO ;)

I think a saner alternative to integrating GVFS into KIO would be to support
the IO-transfer API in use (assuming they use an out-of-process model, if they
don't we can just fork() kio-gio bridges though.  I wonder if this is how
nf2's bridge works? :)

Once we can support KIOSlaves and GIO from KIO then perhaps we can standardize
a IO virtualization interface on XDG so that the actual IO backends of KIO and
GVFS could be used interchangeably.  (This also allows for the backends to be
implemented in languages other than C, which is good IMO).

Really making something like FUSE that "backend API" would probably be best
long-term, except that it wouldn't work under Windows or OS X (and possibly
BSD?)

But either way we don't have to port away from KIO, GNOME doesn't have to port
away from GVFS, but we get the benefit of shared IO backends (e.g. GNOME could
use my kio_perldoc ;)

I'm sure there's more to it than that but I don't see why that can't be a good
starting step.

Regards,
 - Michael Pyne

2009/10/30 Aaron J. Seigo <aseigo@...>:
> On October 30, 2009, Benoit Jacob wrote:
>> Ah OK. That sounds like a more fundamental argument why my proposal
>> won't work in the short-term, and why it would require kernel-level
>> changes that will take a long time to happen.
>
> and for us to decide that newer linux releases are the only kernels we care
> about. there are many other OSes we also support out there.

I never said we should only support newer linux kernels ;)
I proposed some improvements on newer linux kernels while preserving
existing functionality on other OSes.

Benoit

>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>