Re: RFC: Adding zlib dependency to libgio

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.

Therefore i'm a bit worried when too many features get added to this
API (like bookmarks, gdbus,...), which make it less attractive as a
basic free desktop "commodity".

For instance Qt lacks such a VFS API, Thiago Macieira said that he
would like to see a QtVFS. Qt is a very good thing to get more
applications written for the free desktop, IMHO GIO/GVFS developers
should see it as one of their potential customers. Qt can already link
GLib for the main-loop, provide Gtk+ filechoosers, thus moving forward
to full VFS support seems natural. Perhaps QtVFS could be thin
bindings for GIO, designing another VFS API from grounds up doesn't
sound like a good idea, and i guess GIO is portable to the same OSs
like Qt. But i don't know whether there are main-loop issues on

KDE can also use GIO with my KIO-GioBridge ioslave. Not very popular though :-(

I can't really comment on this (de)compression API, sounds like a good
feature. But wouldn't it be sufficient to include some zlib
compression/decompression code in itself?

I also put Thiago Macieira on CC.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]