RE: Maemo's glib version, lobbying for GIO
On Tue, 2008-02-12 at 18:46 +0200, ext [EMAIL PROTECTED] wrote: Philip wrote: 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. Umm, glib generally has nothing to do with toolchain. glib != glibc -- Tommi Komulainen[EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo's glib version, lobbying for GIO
On Tue, 2008-02-12 at 17:21 +0100, ext Philip Van Hoof wrote: My questions ... Therefore I wonder about what the plan is for Maemo's glib version. How soon will Maemo upgrade? What can we do to help speeding up GIO's inclusion into Maemo? Would a standalone version be acceptable? In general we prefer stable releases (personally I'd say starting from .6 or so) but we also backport specific things. At the moment there is no strong demand for GIO so it's not too high up in priority list. We'll get GIO latest when we upgrade to 2.16. Then again GIO is just an add-on so it could be easily introduced without breaking anything, but all work requires resources we could currently use more elsewhere. I mean you'd need to do things like coming up with a migration path from no-GIO - glib-without-official-GIO - glib-with-GIO, figure out when to introduce what (taking into account release plans we're not at liberty to discuss - duh!), how/who would deal with bugfixes and periodical catchup with upstream, etc. -- Tommi Komulainen[EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo's glib version, lobbying for GIO
On Wed, 2008-02-13 at 08:14 +, Tommi Komulainen wrote: On Tue, 2008-02-12 at 17:21 +0100, ext Philip Van Hoof wrote: My questions ... Therefore I wonder about what the plan is for Maemo's glib version. How soon will Maemo upgrade? What can we do to help speeding up GIO's inclusion into Maemo? Would a standalone version be acceptable? In general we prefer stable releases (personally I'd say starting from .6 or so) but we also backport specific things. At the moment there is no strong demand for GIO so it's not too high up in priority list. We'll get GIO latest when we upgrade to 2.16. Strong demand will happen as soon as people start picking it up, of course. People will be picking it in during the following weeks, during the Berlin Hackfest and after the hackfest. I'm confident the conference at FOSDEM will make people even more aware of the benefits of standardising on for example async APIs, stream APIs and etcetera. I promised one of the developers in #nautilus to give him my 770 if he maintains and ports gio and gvfs. He sounded very enthusiastic about this. I also made a quick port of just GIO myself which you can find here: http://pvanhoof.be/files/gio-ugly-maemo-port.tar.gz Then again GIO is just an add-on so it could be easily introduced without breaking anything, but all work requires resources we could currently use more elsewhere. That's right. So far only goffset is a newly used type that Maemo's glib doesn't have a typedef for. I mean you'd need to do things like coming up with a migration path from no-GIO - glib-without-official-GIO - glib-with-GIO, figure out when to introduce what (taking into account release plans we're not at liberty to discuss - duh!), how/who would deal with bugfixes and periodical catchup with upstream, etc. Ok. So I promised my 770 to somebody if he gets GIO and GVFS packaged in maemo-extras. He promised me he'll maintain it after that too. His name: A. Walton. I don't yet know whether he'll succeed/proceed of course. If not, I might do it. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo's glib version, lobbying for GIO
On Tue, 2008-02-12 at 18:46 +0200, [EMAIL PROTECTED] wrote: [Bla bla] 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 http://pvanhoof.be/files/gio-ugly-maemo-port.tar.gz Have fun -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo's glib version, lobbying for GIO
I would like to second the request for a modern glib in the next ITOS release. -- Oohbuntoo is an ancient african word meaning, not just a big bucket and a scheduling calendar for sharing access to the modern science of linguistics in the bathroom. --leeta http://www.gnu.org/philosophy/shouldbefree.html ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo's glib version, lobbying for GIO
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
