[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

--- Comment #80 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-02-16 01:50:32 UTC ---
(In reply to comment #79)
> In next, *every* non-core interface is versioned. Did you see that?

Yes, and I agree with your versioning strategy as described in the commit message for 7fb519ab43f34.

> I think in next, tp-glib should generate code for everything,
> depending on the interface name, not the node name. So, generate
> tp_svc_connection_interface_vengaboys1_call_go_to_ibiza for
> im.telepathy1.Connection.Interface.Vengaboys1.GoToIbiza in node
> Connection_Interface_Vengaboys. I
> guess we'll need to version node names so we can generate code for
> both versions of Conn.Iface.Vengaboys{1,2} but that's an
> implementation detail.

Sure, that's fine. We'll also need to change the filenames so we can *have* both versions (let's keep the filename == nodename.replace('/', '') + '.xml'
invariant, it's probably the easiest-to-understand).

I believe the rationale for unversioned codegen until the first stable version was this. Suppose you have an interface Vengaboys1 with GoToIbiza and Party
methods, then you realise GoToIbiza needs an extra parameter or something. In the approach you're advocating for 'next', you also have to replace all calls to
..._vengaboys1_call_party with ..._vengaboys2_call_party, even though the signature and semantics of that method didn't actually change. That advantage stops
applying as soon as you remove the draft/final distinction and generate ABI-stable code for all versions, though; so for 'next', let's do what you said
instead.

For Conn.I.Addressing1 in master, I thought it was probably better to be consistent with Room2, RoomConfig1, Subject2 and Call1 (none of which have versioned
filenames/node names/codegen) than to apply that simplification. Do you agree? (This also affects CaptchaAuthentication1, which we want to land soon.)

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