John (J5) Palmieri
johnp at redhat.com
Mon Nov 14 07:24:03 PST 2005
On Mon, 2005-11-14 at 12:54 +0000, Daniel P. Berrange wrote:
> On Mon, Nov 14, 2005 at 12:20:10PM +0000, Robert McQueen wrote:
> > Havoc Pennington wrote:
> > > Historically my thought on that has been to just use the COM rule (if
> > > you change an interface you rename it). I think the COM rule is probably
> > > right for *breaking* an interface at least...
> > This is reasonable, I'm not too keen to waste time arguing it. :)
> Much as I hate to further open a can of worms when we're so close to 1.0, this
> idea of interface renaming when breaking API doesn't seem to particularly nice
> Thinking about the implications of applying the rule in a real app - say there
> is an interface defining the API contract for a music player with the name of
> 'org.example.Music.Player'. Now with a new release, the API is broken for whatever
> reason, so the interface has to be renamed - how should a new name be chosen ?
> a) Think of some synonym for 'Music Player', perhaps deciding to rename
> to something like 'org.example.Audio.Player'.
> b) Just tack a number onto the end of the interface name, getting
> something like 'org.example.Music.Player2', 'org.example.Music.Player3',
> etc, etc.
I'm not endorsing the idea just yet but this is how it would work under
Havocs proposal. Say we do have a org.freedesktop.MusicPlayer interface
spec I would think if the spec breaks the API (which it shouldn't do if
it is an adopted standard) you would just rename the interface to the
spec's major number - org.freedesktop.MusicPlayer.v2.
John (J5) Palmieri <johnp at redhat.com>
More information about the dbus