Re: GNOME Namespace Management - ARC & GNOME




Mike:

Sun's idea
  of ABI compatible means something more like "you can take
  a GNOME 2.0 application package/rpm and install it on a
  system with GNOME 2.6 and it will work.

That's the promise that we make about the Developer Platform. That's been
fairly successful. Where it's not, a fuss should be made, ideally during
the development cycle.

It's not, the promise is that the ABI as defined by things like symbol
naming, structure sizes, on disk formats etc are stable. However, changes
which break both applications and bindings, including GNOME itself, have
been made. A fuss was kicked up and ignored.

Well, the GNOME definition is a bit confusing.  It states:

   Do not break ABI. For instance, if an application uses 2.6.0,
   installing 2.6.1 should not intentionally break that already-installed
   application.

So, the current definition does state that you shouldn't break an already
installed application.  This implies supporting interfaces that are not
binary.  However, the "Do not break ABI" part could easily mislead some
people into thinking that only binary interfaces need attention.

You're right, there's a lot that GNOME gets right about interface
stability. It's a leading light in the free software community in many
respects. But there's a middle ground here that people ignore: what
happens when changes are made that break software but fall outside the
maintainers definition of ABI stability?

In this case, it's possible to be both ABI stable (by the strict
definition of ABI) but not semantically stable, or to make changes that
are technically bugfixes but nonetheless break some significant (number
of) programs.
What I've been trying to figure out is how far Suns
commitment extends: take the example of GObject construct only properties.
Would ARC have let this change through, if glib was written by
Sun?

ARC would let such a change go through if the team responsible for GObject
dealt with the change in a manner that supports users of the interface.
ARC would want the team responsible for GObject to ensure that it made
reasonable efforts to identify what programs would be affected and to
work with them to ensure that any user upgrading GObject also upgrades
any affected programs at the same time.

If such a change caused a user program to break, then Sun would have to
figure out how to appropriately patch the system to keep things working
for that user.  Keeping multiple versions of a library on a system, for
example, might be an approach that would be used to support such users.

The point of interface stability in Sun is not to prevent change, but
to ensure change happens in a controlled fashion.

--

Brian




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]