[Bug 26866] Conn.I.Addressing etc. — requesting handles for a vCard field or URI

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26866

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonny.lamb at collabora.co.uk,
                   |                            |will.thompson at collabora.co.
                   |                            |uk

--- Comment #74 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-02-14 07:28:47 PST ---
(In reply to comment #73)
> The problem is that we haven't decided what to do with versioned interfaces.
> Should we make the generated proxies public? The generate class is named ConnectionInterfaceAddressingInterface (not including the version number).
> What if the interface changes to Addressing2 and breaks API? Should we
> generate the class as ConnectionInterfaceAddressing1Interface instead so
> we can generate both when Addressing2 is around? Or should we make all
> versioned interfaces internal now, much like what we do for DRAFT interfaces?

In telepathy-glib, the generated code uses the (unversioned) node name from the spec XML to generate the C bindings, so if we break a versioned interface,
we'll break telepathy-glib anyway.

I think tp-qt should follow tp-glib here: use the node name to decide what to call generated stuff, and if we break it in Addressing2, we'll have to change the
node name to ..._Addressing2 (leading to tp_svc_connection_interface_addressing2_get_new_thing() or whatever, which is admittedly ugly, but that'd be our fault
for getting it wrong the first time and needing to break ABI).

I believe the rationale for the node name not initially being versioned was that when early drafts break ABI but leave the node name the same, you don't have
to run sed over the bits that didn't change just to replace Foo1 with Foo2, only fix the things that actually changed - but when generating code for a
"hopefully final" versioned interface, that doesn't apply, since Foo = Foo1 has effectively become part of the API. At *that* point, you have to version the
node-names of subsequent versions.

I think this situation could make sense, for instance:

* design Foo1, generate code as Foo, implement in Gabble,  find that it's
  wrong
* design Foo2, generate code as Foo, fix Gabble to compile again,
  implement in Empathy, find that it's still wrong
* design Foo3, generate code as Foo, fix Gabble/Empathy to compile again,
  everyone's happy, "ship it", declare stable, add to tp-glib & tp-qt
* discover that to support Gadu-Gadu or something, we need a Foo4;
  generate code as Foo4 and have it as a second, parallel stable version

Versioned interfaces were mostly wjt's idea, I think. Will, if I'm not understanding this correctly, please correct me :-)

> We would also have issues with the high-level API when/if versioned
> interfaces changes, as the changes may affect high-level public API
> (we could deprecate them if needed, but still an "issue").

Yes, this is unavoidable (and this is why we shouldn't be too keen to add high-level API for things that are not necessarily fully-designed yet). We shouldn't
merge high-level API until we're reasonably sure about it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.