[Bug 24936] Channel.Type.Call (StreamedMedia 2.0)

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24936





--- Comment #12 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-12-01 05:43:14 PST ---
Stream.I.Media (also see updated smcv/call branch for some editorial fixes):

* ServerInfoRetrieved and RetrievedServerInfo are ambiguous member names.
Without looking at the spec, try to tell me which one is the signal and which
one is the boolean property :-) Can we disambiguate these better?

* It is claimed that STUNServers cannot change once the stream has been
created. This seems likely to be a lie, given that we now have change
notification of a sort? It should have proper change notification, though, if
it can change (perhaps just an "added" signal).

* Likewise, what is RelayInfo's change notification?

* Does it ever make sense to remove a local candidate? If it does, we'll need a
LocalCandidatesRemoved signal

* What is LocalCredentials and what is its rationale?

* LocalCredentials will need to be a named <tp:struct> (or a pair of string
properties), otherwise telepathy-qt4 will be unable to bind it

* How many times can LocalCredentialsSet happen? 0-1? 0-infinity?

* Does SetCredentials() change LocalCredentials? How many times can it be
called?

* What is a candidate anyway? What is a component anyway? (Perhaps this
interface is only meant for use by people who speak fluent RTP, but I'm only
dimly aware of what a candidate is...)

* Am I right in thinking that Stream.I.Media deals with local candidates (ways
in which the local user tells remote users that we can perhaps be contacted)
while remote candidates (ways in which remote users tell us they can perhaps be
contacted) are all dealt with by Endpoint? The (missing) introductory docstring
should say this sort of thing.

* If I infer correctly that LocalCredentials, LocalCandidates come from the
streaming implementation and nowhere else, do they actually need to be readable
at all, or can they be "write-only" (i.e. not exist as properties at all, only
as setter methods)?

* In Candidate_Info: we conventionally use "g-object-case" for un-namespaced
bags of strings, and reserve CamelCase for D-Bus properties. Or is there some
external thing we're being consistent with?

* The descriptions in Candidate_Info aren't sufficient for me to understand
what they're for.


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