[Bug 24906] GSM-compatible conference calls

[bugzilla-daemon at freedesktop.org]

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

--- Comment #26 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-04-14 10:47:00 PDT ---
Regarding EnsureChannel with InitialInvitee{ID,}s:

18:09 < smcv> jonnylamb: if ensuring, their semantics would be quite odd - "if 
              no existing channel, make one and invite these, else do nothing 
              to the existing channel"
...
18:27 < smcv> jonnylamb: the "what does it mean when ensuring?" thing is 
              irritating, and could do with either a special case (when there's 
              an existing channel, those people/channels get invited/merged) or 
              a warning

Regarding InitialInvitee{ID,}s vs. InitialChannels:

18:32 < smcv> so there are two purposes
18:32 < smcv> 1) request merges
18:33 < smcv> 2) when seeing a new channel, know wtf is going on
18:33 < smcv> for the former you can use any or all of the three properties, 
              and what you're actually asking for is the union
18:33 < smcv> for the latter, it seems best to offer as much information as 
              possible
18:33 < smcv> "this channel is an upgrade/continuation of C1 and C2, and is 
              talking to H1, H2, H3 (that's I1, I2, I3)"
18:34 < smcv> where Cn are channels, Hn are handles, In are identifiers
18:34 < smcv> constrained by the need to decide what you're going to announce 
              before you announce it, and not change it thereafter
18:34 < smcv> does that make sense or am *I* not being clear this time? :-)
18:35 < jonnylamb> Okay, yes I get this now. I think I was just confused with 
                   the InitialInvitee* name.
18:35 < smcv> do you think the current semantics make sense, assuming we rename 
              to InitialMembers/InitialMemberIDs or something?
18:36 < smcv> I think you're right that the name is confusing
18:37 < jonnylamb> Well I'm not /so/ sure about making Initial* a union. We can 
                   find out the members using the group interface (and in 
                   practice that's what everyone will do).
18:37 < smcv> yeah, true
18:37 < jonnylamb> I'm more in favour of keeping the name Invitee and making it 
                   do what it sounds like it will do.
18:38 < smcv> fair enough
18:38 < jonnylamb> So when your new channel is announced, if InitialInvitee* is 
                   set, you can know that that contact(s) was invited when the 
                   channel was created, and in practice: "this is the contact 
                   that necessitated this new channel".
18:39 < smcv> ok
18:39 < jonnylamb> Does that sound reasonable?
18:39 < smcv> to a point
18:39 < smcv> InitialInvitees should still be the union of the requested 
              InitialInvitees and the handles of the requested
InitialInviteeIDs
18:39 < smcv> and vice versa
18:40 < smcv> (so you can look at the one you prefer to work with, and ignore 
              the other)
18:40 < jonnylamb> Oh, yes I totally agree with that.
18:40 < jonnylamb> Same semantics as Target{Handle,ID} really.
18:40 < smcv> bonus points if you devise a good wording for requiring them to 
              be in a corresponding order on channels, without requiring them 
              to match up in requests
18:41 < smcv> but yes, that makes sense

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