faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: kio-gio bridge
by SadEagle on Tuesday 22/Jan/2008, @15:04
|
> Well - in theory KIO could be implemented desktop independent, that's true. > But in praxis rewriting the client and daemon/slave parts isn't easy. As > GIO/GVFS already is desktop independent in the implementation, and also seems >to have some advantages in design, why not go for it?
First of all, there is no reason to rewrite anything. Multiple implementations can talk on the same wire protocol. And GIO is "Desktop independent"? That's just nonsense, to put it politely. It's written exact way GNOME developers like to write things. And "why not" throw out something that works pretty well for a new toy, just because GNOME is being NIH again? Are you being freaking serious?
> Why is it overlapping? Parts of the functionality in KIO (particularly
> network transparent file-management like smb, ftp, sftp, webdav) would be
> delegated to GIO/GVFS. That's just putting the KIO interface on top of a
> shared implementation.
Because you would need the core KIO infrastructure for things like kio_http, kio_imap4, etc. And as someone who may have to fix things in kio_http, I sure as heck won't want to deal with a mismash of g* code in KIO core. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: kio-gio bridge
by Kevin Krammer on Tuesday 22/Jan/2008, @15:53
|
> First of all, there is no reason to rewrite anything.
I think he didn't mean to use the word "rewrite", i.e. replacing an existing implementation with a new one, I am quite certain he meant "from ground up", i.e. starting to implement a second stack starting at the wire level.
> And GIO is "Desktop independent"?
Again I think this is just unfortunate wording. In this context it more likely means "not linking against any GUI library", e.g. an implementation just linking with QtCore would also be "Desktop independent".
|
[
Reply To This | View ]
|
Re: kio-gio bridge
by Norbert on Tuesday 22/Jan/2008, @17:27
|
>> First of all, there is no reason to rewrite anything.
>
> I think he didn't mean to use the word "rewrite", i.e. replacing an existing
> implementation with a new one, I am quite certain he meant "from ground up",
> i.e. starting to implement a second stack starting at the wire level.
Yes, thats right.
> And GIO is "Desktop independent"?
>
> Again I think this is just unfortunate wording. In this context it more likely
> means "not linking against any GUI library", e.g. an implementation just linking
> with QtCore would also be "Desktop independent".
Yes, exactly. It's not possible use KIO and it's protocol handlers without installing and running some KDE specific stuff at the moment. Perhaps that's all more on the edges of KIO, but it makes it less attractive for using it cross desktop.
|
[
Reply To This | View ]
|
|
Re: kio-gio bridge
by Norbert on Tuesday 22/Jan/2008, @19:03
|
> And "why not" throw out something that works pretty well for a new toy, just because GNOME is being NIH again?
I don't think it's fair to call it a "toy". They have implemented something that from design comes very close to what has been discussed since many years ("D-VFS", "Common-VFS", "Shared-VFS",...). Unfortunately it was not there before KDE4 development started.
> Because you would need the core KIO infrastructure for things like kio_http,
> kio_imap4, etc.
Sure, but they are kind of in a different domain (used internally by certain KDE applications).
I agree that what i'm proposing looks a bit weird, it's just that i don't know of a better pragmatic solution.
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
