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

[Pierre]

On Monday 02 November 2009 14:08:06 nf2 wrote:
> On Sun, Nov 1, 2009 at 8:23 PM, Pierre <pinaraf at pinaraf.info> wrote:
> > On Sunday 01 November 2009 20:12:34 nf2 wrote:
> >> On Sun, Nov 1, 2009 at 6:33 PM, Dario Freddi <drf54321 at gmail.com> wrote:
> >> > On Sunday 01 November 2009 17:50:56 nf2 wrote:
> >> >> 1) Putting a different label on an already existing system, like I
> >> >> would suggest: "This ist the standard system for the major
> >> >> file-management protocols, thanks, problem solved". Technically easy,
> >> >> but won't work because there are understandably different opinions on
> >> >> which one to pick.
> >> >
> >> > Renaming is technically easy. What about porting? What about kio_http
> >> > and protocols not supported by GIO?
> >>
> >> HTTP is an important protocol, but not so much for basic
> >> file-management. You will hardly run across it in Dolphin or in
> >> file-choosers. And where it is, it's probably just downloading a file
> >> via HTTP GET, which is provided by both systems already. The extra
> >> features kio_http provides, are tailored for certain KDE apps using
> >> them. So there is no reason to change the status-quo here (But it's
> >> relationship with webdav might be a challenge).
> >
> > Ok, let's suppose I browse a website requiring authentication using
> > Konqueror (through kio_http). I click on a link that opens with another
> > application. This application uses the GVFS http handler. That link won't
> > work since cookies won't be kept, nor will Http:basic authentication
> > "tokens"...
> > Having a common dbus api for both gvfs and kio seems much better from
> > that point of view since the application would then "automatically" use
> > KIO, wouldn't it ?
> 
> Well - yes - i kind of expected this argument. Tricky.
> 
> On the one hand I could just say: Ok - my proposal can't solve every
> problem in the world.
And now, the proposal suggested by many people on this list can solve this : 
define a common fd.o API for IO, implement it using KIO, another implementation 
using GIO, another using the Hurd translators if you want... et voila. It'll be 
up to the applications to use that standard API instead of specific ones. That 
would be much simpler and future proof. With your solution, what would happen if 
GIO disappears and is replaced by yet another system ? We switch to that new 
system too ? So great... 
There is no evidence that any of the existing systems will live for a "long" 
time (microsoft has over 15 years of binary compatibility, compare that to any 
linux system...) 
Relying on any of them is not a solution. Neither KIO nor GIO is universal, 
neither is gonna be totally acceptable by the other side.

And can GIO_http be improved to that level ? and will it be possible to share 
cookies, http:basic auth... Also, don't forget that only one download must be 
done, you sometimes aren't allowed to download a file twice.


BTW, I know, I speak even if I am nothing from a KIO point of view. But I am an 
user, a "small" developer (running seriously out of time, else I would look at 
how to build a common fd.o API), and I don't feel good when I see that you want 
to build a de-facto standard using a gnome API that is not even two years old... 
KIO exists since 9 years. That just doesn't feel fair, do you really want to 
drop all that amount of work ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091102/66e4de8a/attachment.sig>