Re: RFC: Adding zlib dependency to libgio

[nf2 <nf2 email gmail com>]

On Mon, Nov 9, 2009 at 12:23 PM, Alexander Larsson <alexl redhat com> wrote:
> On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote:
>> On Sun, Nov 8, 2009 at 10:54 AM, Alexander Larsson <alexl redhat com> wrote:
>> > I've been working on some API for gio (more details later) that involves
>> > having an API for (de)compression. Having this as a public API makes
>> > zlib a mandatory dependency for libgio (and thus the glib tarball).
>> >
>> > We already have a dependency on zlib from gdk-pixbuf, so all Gtk+ apps
>> > already pull this in, however there could be non-gtk+ using glib apps
>> > that now get an additional dependency. Its a very small (74K .so) and
>> > very widely availible/used library though, so I don't think this is a
>> > huge deal.
>> >
>> > Anyone who thinks this is a bad idea?
>> >
>>
>> Well - as I already said earlier, I think GIO - in the long run - has
>> a potential of becomming *the* free desktop API for file-management.
>> Simply because it's design is modern, universal and reminiscent of IO
>> APIs, which people already know from other programming languages (i.e.
>> Java). And it's sitting very low in the stack. Such an API is hard to
>> design and takes long to consolidate.
>
> I know you're really interested in cross-desktop VFS support, and I
> don't disagree with having something like that. However, the fact is
> that libGIO is an important part of the Gtk development stack, that
> contains all the stuff that developers that want to write Gtk+ apps
> want. Just like Qt contains all that Qt developers want/need. We will
> never artificially limit our platform just because of cross-desktop
> compatibility.
>
> And additionally, I don't see GIO as the thing that should really be
> shared between glib and Qt, but rather GVFS. I'd much rather see some
> cooperation between the gvfs and Qt people to stabilize the gvfs
> protocols such that Qt could directly talk to gvfs mounts.
>
> Obviously some could could be shared, but a straight dependency on
> libgio isn't necessary.
>

Hmm... I don't really understand the neccessity to rewrite the entire
GVFS client in Qt/C++. All the other programming languages use
bindings, therefore why should Qt/C++ be different?

* While writing a pure Qt/C++ client would certainly be possible
(apart from the issue with the UriMappers), it would be a huge effort.

* With one disadvantage: Standardizing all the D-Bus mechanics inside
GVFS would probably make it harder to move forward. My feeling is that
it's always the best approach to define the stable public interface at
the "narrowest" part of the chain. Which not neccessarily has to be
the IPC part.

* Just compare this to libdbus: The IPC protocol is standardized, but
almost everyone uses the libdbus as "the real interface".

*  "libGIO is an important part of the Gtk development stack". Yes,
but - at least at the moment - it doesn't carry a lot of things in it,
which are Gnome/Gtk specific. Most of the things are either the
implementation of freedesktop-standards, or GVFS related. So it just
looks like the "all you need for file-management" API, I just can't
help it. And in my opinion it's a really cool one. Sorry, Alexander,
that i'm asking to put a different label on it. I think GIO deserves
to be more than a detail in the Gtk stack. :-)

* I think if GIO/GVFS can pull Qt and KDE into their boat, this would
be an important signal for all the 3rd party applications to link a
proper VFS interface. Because at the moment many of them won't, as
this implies deciding for a certain desktop environment.

* Hopefully, one day people will realize, that KDE, Gnome and Qt are
kind of living in the same appartment. There is no way to escape from
that - independence is a dream. For one simple reason: applications,
applications, applications. They are the most important desktop
feature, the primary reason to buy a computer. So what's the point of
having all the "infrastructure" duplicated: The toaster, the
dish-washer, the washing-machine... ;-) This duplication just causes
an enormous amount of chaos.

However, i think a pure Qt implementation of GVFS would definitely be
a very important move into the right direction.

Cheers,
Norbert