Platform, platform, platform (and integration!)
WARNING: Here follows a rant from a person without deep insight into the whole history of Gnome 2.0, but nonetheless feels qualified to give some constructive criticism.
Did anyone notice the 3 platforms in the title? That is no coincidence, because I am going to talk about platforms and my vision for Gnome 3.0.
It will serve you well to read Imendios vision of Gtk 3.0 before you read on.
Today
Desktop and Platform?
Currently Gnome is split in two parts, Platform and Desktop. If you want the formal definitions follow the links. Here are my version of the definitions:
- Platform: Rock stable functionality. API and ABI guarantes. If anything here breaks you get to spank us and call us animal names
- Desktop: If you have a dependency you don’t really know what to do about (and don’t like to #ifdef al lot) then lobby bit to convince people to put it here. These libraries should strive to remain API stable, but no guarantees given.
So the platform module sounds promising – how do you feel about the desktop module? Not too keen? Well some of the libs in desktop have individual API promises, but you get to figure that out for yourself. This project structure makes it very hard to get into platform (which is sane in this situation of course) and a lot easier to get into desktop.
Then you start skimming the list of platform modules (they do not appear in the listed order):
- glib – check
- gio – check
- gvfs – check
Very sane so far
- gtk+ – ofcourse, check
- 4 libs for dealing with Bonobo/Orbit – wtf?
- libart_lgpl – wtf? Don’t we have Cairo these days? Supposedly only used by the canvas widget.
- 4 seemingly Gnome-utility libs (libglade, libgnome, libgnomeui, libgnome-canvas) – wtf?
I must be frank an say that as an outsider (in the sense that I have not been part of the decision process) the Gnome stack looks a bit like a mess. Putting it bluntly, only GLib (and its modules) and Gtk really seem attractive. Gnome does not really feel like a “platform”, it feels like a collection of libs. There I said it. Sorry.
My Vision
In short: More “plaform”, less “collection of libs”. Read on.
API and ABI Stability
As also proposed by Imendio (although mainly about Gtk+, where I am talking about the Gnome stacck) libs should not expose struct fields or other variables. Everything goes through getter and setter methods. This should make it a lot easier to maintain both API and ABI stability.
Release Schedule
6 months for minor versions. 3 years for major versions. Why force a major version bump every three years? This is highly dependent on the Desktop, Platform, Core section below which you should read before flaming me. Other benefits of a forced 3 year major release cycle:
- Satisfy the feelings that the types of users and developers who want Gnome 3.0 now have. Note that this has nothing to do with the technical aspects – feelings are emphasized. If major releases make people happy I say we make them happy
- Selling point for distros. “Our brand spanking new version of FoobarLinux comes with the shiny new Gnome 2.22.2.4.5.1.4 as opposed to the the former release who shipped 2.22.2.4.5.1.3″, or sed that with s/2.22.2.4.5.1.4/4.0 and do the math on the total revenue
- Keep things moving. Give developers a window of opportunity to bring new technology into the stack. This is possible today, but it is more inspiring to push for a major release
The underlying idea here is to be more loose around the major releases because of human emotions not technical issues. We should not underestimate how important motivation is.
Desktop, Platform, Core
- Core: As platform today. Very hard to get in here, but with less cruft. Rock stable API adn ABI. Both are stable between major releases, this is more easy to maintain because of the new strategy noted under API and ABI Stability above. The idea is that other platforms such as XFCE or mobile platforms should also be able to depend on Gnome Core.
- Platform: API stable between major releases, not ABI stable. ABI stability is only per major release number. Proprietary applications depending on Platform will have to distribute binaries for each major release.
- Desktop: API and ABI stable per micro release (X.Y.*) in addition Gnome promises that the functionality in here is persistent for the whole major release cycle. Stuff might change API or even be moved to another lib, but you will still have a way to achieve the same effect without much hazzle.
Specifically for Core and Platform there is a “No Technology Leaking” policy. This means that we are not allowed to expose stuff from underlying libs such as X. Also for Platform and Core it is strictly verboten to stick application/lib-specific dependencies in here (libart, libeel). With Core and Platform you should be able to write just about any application. Desktop would contain the sugar to integrate with the official Gnome apps, and more specialized libs that a not of broad usage.
Namespacing – Especially for Core and Platform, but also to some extend for Desktop, we should be more aggressive about namespacing things under a g*-namespace. This gives a more coherent feeling. See for example libart, libbonobo, liborbit, libebook, et al. I realize that we cannot shovel everything into the g*-namespace, but can we just try harder?
Today Desktop contains cool stuff like GStreamer. Since GStreamer is not under the control of Gnome we can not really put it into Platform even though it might be cool to have there (if you don’t like the GStreamer example pick any other cool lib from the current Desktop module). To get such cool technologies into Platform or Core Gnome could be more aggresive with API indemnifying wrapper libs. While I am not sure I am all for what KDE has done with Phonon, a less aggressive solution could be fine to me. For example just creating a thin wrapper flexible enough to absorb underlying API flux, but not fat enough to flex out backends and other funkyness.
Specification, Abstraction, and Implementation
I am very exited about the “recent” trend of writing FDO specs and then implementing these (recent – like over the past years). I think we could a gain a lot from pulling more in that direction. Take for example the case of panel applets. If there where a clean specification for the construction and interactions with these then other platforms would have the opportunity to embed Gnome applets as well, without pulling in the whole stack. Since we are not allowed to leak underlying technologies we can not let the applet spec rely on XEmbed or X at all for that matter. Now who said GtkBuildable/DBus with some magic introspection glue? This could mean that Gnome applets could eventually run under KDE, XFCE or OS/X or WIndows.
Not all specs has to go through the FDO machinery. Gnome specific specs are also fine as long as they are stable like our APIs and respect our layering.
As also hinted in the paragraph about “API indemnifying wrapper libs“, abstracting out some of our dependencies could bring us a lot of flexibility and possibly a host of new developers. With the help of an officially adopted IDL writing thin abstraction libs could be made quite easy.
Example
Just to make it clear about the proposed trinity of Gnome modules here’s a quick rundown of how it could look like:
- Core: Glib (and modules), Gtk+, Some dbus stuff, a networking lib, XML. Basic accessibility
- Platform: Lib for desktop search, and metadata management. GConf/DConf, libwnck, libxklavier, libgtop, gtksourceview, gstreamer, keyring etc. More advanced accesibility
- Desktop: Lib to remote control Nautilus and other high profile apps, specialized (for audio/video, or images, etc) metadata handling libs (exempi for instance), panel integration, libart, librsvg,
Thanks for following me this far. Let the public humiliation commence (remember I am allowed to dream 
).
Update: Let me underline that I think we achieve a lot of this by using the codebase we have already. We need some extra spice (and IDL would come in handy) and then we’d probably need to break some API (not that much really) and remove a lot of deprecated modules. A lot of work, but not ridiculously much. Are we a team?
March 13th, 2008 at 05:33
I’d add a fourth suite called Compat for obsolete stuff like esound, bonobo and libgnome.
March 13th, 2008 at 05:39
You are preaching to the choir. http://live.gnome.org/LibgnomeMustDie
March 13th, 2008 at 05:47
(I’d also require one to pass -DI_KNOW_LIBfoo_IS_OBSOLETE to build against obsolete components.)
March 13th, 2008 at 07:44
The GStreamer API has been as API/ABI stable as, for example, glib for the past 3 years now with the 0.10 series. We occasionally add API/deprecate old API, just like glib does. Creating a thin wrapper lib for API/ABI reasons is a bad idea in the GStreamer case, IMHO. Just wanted to mention.
March 13th, 2008 at 07:50
Writing wrappers for everything sucks. Usually the life-cycle for a wrapper is about the same (or less) than the thing it wraps. I’d propose something different: Core – glib + modules, gtk+, dbus, gstreamer, networking lib, xml, basic accessibility
March 13th, 2008 at 08:10
@Patrys: Well, that depends on our goals for G3. If the goal is (like I would like) to clean up the base, then I would ditch compat. Just more work for maintainers and distros alike to keep stuff working.
@Rob: I am fully aware of the “libgnome must die”-mission. What I maybe failed to get across was the lack of coherency and laid out goals for the Gnome platform.
I think:
– The two top-level modules-approach is bad
– The definitions of these modules are unclear at best
– The “What-do-we-aim-for” is entirely missing in Gnome (libgnome-must-die is not a “goal” it is merely cleanup in my eyes)
March 13th, 2008 at 08:27
As a long time Gnome user I fully agree with the “collection of libs” statement. I feel this also makes it harder for new developers to join, especially if they are used to other platforms.
Even if not everybody agrees, constructive discussions like this and the Gtk+ 3.0 discussion will bring Gnome forward.
March 13th, 2008 at 08:58
@wtay: Yeah, the gstreamer example might have been a bad one since the API is stable already. However there is no clear statement about Gnome “proxying” this API stability. As I also mentioned I don’t want to wrap everything like they more or less did in KDE 4, but in some places it might make sense.
@npmccallum: As in my response to wtay, I can easily imagine gstreamer in Core if Gnome has some official means to guarantee the stability of the API (over major releases) – otherwise it would need to go in Platform.
March 13th, 2008 at 10:36
kamstrup:
I didn’t mean to support or develop these libraries. I’d leave them to bitrot there until the next major release so ISVs can fix their apps (hence the -DI_KNOW_I_DONT_WANT_TO_USE_THESE). The goal was to move them away from the main libraries so we can get something closer to OSX (core multimedia, core hardware, core web, core this, core that).
March 13th, 2008 at 11:17
Your layout for core, platform, and desktop sounds sane. Although I think it important to determine how different programming langauges fit into this structure.
For example, Core definitely seems like a C only type of environment. My first guess would be that Platform can also only be written for in C. After that you have a “Bindings” layer that can be used by anything in Desktop?
I don’t think it needs to be difficult, just clearly defined.
March 13th, 2008 at 14:25
@Patrys: So you mean include deprecations for $major – 1..? That sounds sane. If we don’t want to provide a lot of wrappers I don’t think a layout like core hardware, core web, core foo, etc is possible. This is open source an people generally develop what they feel they need (unless they are paid). Therefore we should not expect a clean structure like that. The concept of Core, Platform, and Desktop is somewhere in between what we have now, and the really clean approach like Apple’s.
@Pete: I think you are spot on with regards to language bindings. Gnome 3 would really provide an opportunity to think this into the design of Gnome as a whole. Where and how they are layered in the stack.
March 14th, 2008 at 01:49
This seems like a _very_ vendor hostile proposal. If the platform is going to break every 3 years, then the expected lifetime of an application is going to be 1.5 years.
It is also hostile to the distribution vendors, who need to be able to support a particular version of GNOME for an extended period. With 3 year ABI breaks, a vendor might end up supporting a version two or three ABI breaks behind the current version. Given that a significant proportion of GNOME developers work for these distributors, this is going to draw their attention away from the latest version.
If the only reason to break the ABI is a version number bump, lets just bump the version number — no need to break everything.
March 14th, 2008 at 08:31
@James: The Platform is not going to “break” every three years. You’d have to recompile any apps using the Platform module for each major version, yes, but don’t distros compile their binaries for each Gnome release now anyway?
I admit that I have never worked for any distribution vendor, but I can’t see how ABI breaks make it harder to maintain the distro. Upstream code changes that do not break API still makes it hard to apply patches and such across several distro releases I would assume. Or where exactly lies the trouble in the ABI break, I might just be clueless.
April 19th, 2008 at 00:27
[...] an abstraction from IDL for any public API sounds like a cool plan, [...]