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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #59 from Sjoerd Simons <sjoerd at luon.net> 2010-06-24 05:15:03 PDT ---
(In reply to comment #12)
> 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?

#28704

> * 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.

#28705

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