Re: Modulesets Reorganization

[Tomeu Vizoso <tomeu vizoso collabora co uk>]

On Wed, Jun 2, 2010 at 01:37, Lucas Rocha <lucasr gnome org> wrote:
> Hi all,
>
> The release team would like to propose some important changes in the way we
> organize our modulesets. GNOME releases are currently organized into the
> following modulesets: Desktop, Platform, Bindings, Mobile, Admin, and Dev
> Tools. This model has served us well and has actually evolved through time - we
> didn't have the Admin and Dev Tools modulesets initially. However, we feel that
> this organization is reaching its limits, and we have explored several
> potential changes.
>
> Current issues
> --------------
>
> A set of issues makes it clear the need for an evolution here:
>
> 1. The arbitrary separation between Platform and Bindings can lead people to
> think that the bindings are second-class citizens while this is certainly not
> the case.

Moving bindings modules to the Desktop moduleset won't make them less
second-class citizens as long as API that is not bindable without
resorting to language-specific glue code keeps being added to
Platform.

Examples of this are GVariant (which affects GSettings) and GDBus, in
the latter this question was raised on gtk-devel but nobody showed
interest in how to make the new functionality available to bindings:

http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00136.html

I don't think the authors of those APIs are to blame for this, because
they asked for feedback before merging and nobody who cared about
non-C languages replied.

It's nice that the release team worries about bindings because lots of
software is written for GNOME in languages other than C. But today we
are seeing a disproportion between the people who use bindings and
those that build them and it worries me a lot. What will happen to
those applications when old APIs such as GConf are not available any
more and GSettings is not available to their language?

An action more in accordance with the intention of making bindings a
first class citizen would be to require new API (with exceptions for
low level glib stuff) to be bindable by the introspecting bindings,
and also maybe some thinking into why the bindings landscape is in
such a mess right now.

Could be something like this be added to the criteria for platform libraries?

Presently, we have this stub for what is considered as "bindable":

http://live.gnome.org/GObjectIntrospection/WritingBindingableAPIs

Regards,

Tomeu