[maemo-developers] Maemo's glib version, lobbying for GIO

[From: josh.soref at nokia.com]

Philip wrote:
> Therefore I'm pleased that at the level of glib a team has started
> working on GIO.
> 
> http://svn.gnome.org/viewvc/glib/trunk/gio/

> GIO not only comes with a streaming API, but also with a standard way
> for making cancellable asynchronous APIs.

http://neutronic.spaces.live.com/blog/cns!6CAF0CCA79C2F340!145.entry
  > The wonderful thing about standards...
  > ... is that there are so many to choose from

I can't speak for anyone, however, I don't expect mozilla to instantly
add gio. It took a while before someone added gnomevfs, and now that's
going to go the way of the dodo (three cheers!)

> It uses the Asynchronous pattern for this which results in types like
> GAsyncResult and a type GCancellable.

> As Tinymail's main developer I would like to start using these types
> as soon as possible (that's instantly after my first release). I 
> would like to standardise on how future glib GObject based libraries 
> will do async APIs that are cancellable and I would like to
> standardise on my stream related APIs too.

http://arstechnica.com/news.ars/post/20080211-samsung-sued-over-defectiv
e-first-gen-blu-ray-players.html
  > Samsung sued over "defective" first-gen Blu-ray players

Jumping to new "standards" can get you in trouble.

> To sooner I can do this, the fewer times my API will need to 
> be broken,

I don't see how this follows. Someone jumping to maemo1.0 has probably
had their impl broken at least yearly (so 4 times?).

> the fewer major releases I have to do. The less headaches development
> teams depending on Tinymail, like Modest's team, will have.

I'm sure they appreciate fewer headaches (I sure would like to have
fewer headaches).

> If after this current distro Maemo would not get a glib for half a
> year that includes a GIO, people like me could be blocked for the 
> entire time from delivering APIs like E-mail ones 

I'm not sure this follows. I'm not a representative of maemo, but if you
look at the history, OS releases have been named after years (2005,
2006, 2007, 2008).

As a normal developer, I wouldn't expect something faster than that.
Looking at product announcements from Nokia,
http://www.linuxdevices.com/news/NS8069179684.html
  > Sprint will offer a Mobile WiMAX-enabled version of Nokia's N800
Internet Tablet to North American customers 

So far most Nokia product releases relating to maemo are either at the
beginning of the year (n800) or at the end of the year (n810). Given an
announcement, and the fact that the device clearly hasn't surfaced yet,
I think it's safe to assume it'd come out closer to the end of the year.

This of course doesn't imply that you get a new OS, it might run 2008 (I
have no idea).

> unless I hack-in a standalone version of GIO (sounds ugly to me,
> but if necessary ...).

> My questions ...
> 
> Therefore I wonder about what the plan is for Maemo's glib 
> version.

Upgrading glib generally speaking breaks the entire toolchain and scares
everyone (for some releases it's attempted and rejected because too many
things break). So it should never be done in the middle of a release
cycle.

The same applies to the kernel, X, gcc, ld, and a number of other core
components - this of course excludes bug fixes [gio is not a bug fix].

> How soon will Maemo upgrade?

(I don't speak for maemo.)
NPTL was added for 4.0
http://maemo.org/development/sdks/api_changes_between_maemo_3_2_and_maem
o_4_0.html
But it was actually a risk item. It could very well have missed even
though most people wanted it.

> What can we do to help speeding up GIO's inclusion into Maemo?

My personal believe is that it's unlikely that there's anything you can
do here.

> Would a standalone version be acceptable?

I think you should try to find a way to get gio to work on the existing
glib and then provide a package which could be installed into existing
OS releases.
Or "yes". Just package it properly and support it. Add it to
maemo-extras and version it well....

> My opinion ...
> 
> .. is that the sooner we have this API in Maemo, the sooner 
> application and- library developers will be synchronised with each 
> other's APIs and IO sharing.

I don't think it'll happen that fast anyway. The sooner people develop
and test w/ gio, the sooner they can start working out some of the bugs.


> For example HTML components need to share IO with the E-mail
> framework (inline attached images in base64 encoding).

I don't think this is truly necessary. Are you planning on loading
hundreds of images at a time?

> The VFS needs to share IO with the E-mail framework (Attachment->Save
As).

I'd rather see fuse implemented.
http://arstechnica.com/journals/linux.ars/2007/09/28/gnome-2-22-planning
-gio-and-gvfs-proposed-for-inclusion

> The media player (hi there Valagume developer!) could share IO with
the E-mail
> framework (streaming an attached MP3), or GStreamer could share the IO
> (a source element that knows about GIO's streams).

Streaming an attached mp3 sounds like a really odd thing to do.

Are you streaming from a file (maildir, mbox), or from IMAP? If you're
streaming from IMAP, what happens when the network disappears?
If you're streaming from mbox, what happens when the mail client gets
stuck doing something else or worse manages to crash?

> A lot of libraries expose asynchronous APIs. At this moment 
> are most of them having their own nuance differences.
> With a generic infrastructure for asynchronous APIs in gio,
> libraries could finally start doing it in a standardised way.

We can't even standardize on a spelling for standarize. :)

> Making things more easy for application developers. Making things more
> easy for language bindings. Making things contain less bugs.

Release early, release often, but don't make promises you can't keep.