Comments on: Platform, platform, platform (and integration!)

By: Debain

Debain — Sat, 19 Apr 2008 06:27:54 +0000

[...] an abstraction from IDL for any public API sounds like a cool plan, [...]

By: kamstrup

kamstrup — Fri, 14 Mar 2008 14:31:04 +0000

@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.

By: James Henstridge

James Henstridge — Fri, 14 Mar 2008 07:49:39 +0000

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.

By: kamstrup

kamstrup — Thu, 13 Mar 2008 20:25:09 +0000

@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.

By: Pete

Pete — Thu, 13 Mar 2008 17:17:51 +0000

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.

By: Patrys

Patrys — Thu, 13 Mar 2008 16:36:31 +0000

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).

By: kamstrup

kamstrup — Thu, 13 Mar 2008 14:58:51 +0000

@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.

By: Dennis

Dennis — Thu, 13 Mar 2008 14:27:03 +0000

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.

By: kamstrup

kamstrup — Thu, 13 Mar 2008 14:10:18 +0000

@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)

By: npmccallum

npmccallum — Thu, 13 Mar 2008 13:50:48 +0000

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