[Jingle] Opinions about Coin
diana-liste at null.ro
Thu Apr 28 20:13:33 UTC 2011
The question here is "Which problem is COIN trying to solve?"
The answer I believe it is "It's trying to make a conference".
Now his purpose it's to control the conference. But Jabber already has a
model for conference which it's based on MUC. That's the Jabber way to
split things in such a way that it can be implemented in layers. So the
negociation shouldn't be done by the client. That should be done by the MUC.
In SIP you can compare the SIP proxys with the Jabber servers. But in
SIP there is no concept for an external component as MUC.
That's why the COIN is considered sipish and it's such a strong opinion
My personal opinion is that clients if they want to do management of a
conference they can do it using iq based commands for MUC as for any
I know that most SIP developers will consider that a far too complicated
way. But sometimes an additional layer it's necessary for keeping the
long term implementation clean.
On 04/28/2011 04:34 PM, Enrico Marocco wrote:
> On 4/28/11 2:14 PM, Dave Cridland wrote:
>>> This is beginning to get too generic and I am afraid I am not
>>> following. Could you please point the aspects in Coin that you
>>> think would prevent XMPP servers to work with one another?
>> I think Diana is saying that the model of COIN is essentially that of
>> SIP, and doesn't conform well to the federation and deployment model
>> of XMPP, which is much more structured and well-defined.
> Yes, that's also what I thought was meant. The problem that I'm having
> is that ever since we proposed Coin the kind of criticism the we've been
> getting has mostly been a variant of "this is not the XMPP way" or "this
> is sooo SIPish" or "this is a kitchensink" or even "read it and it'll
> make you cry." I now wonder when we'll get "every time you read it a
> kitten dies."
> It is hard to argue with such statements so it would be great to hear
> something more specific. As a starter, an example of the issues that
> come with being SIPish in this case -- assuming it is -- would help a
> big deal.
> In this specific case I simply fail to see the paradigm mismatch. Coin
> uses a very simple model that would be easy to adapt to the majority of
> the conferencing applications today. In this model people either join or
> are called into a conference which looks to them as a regular call.
> Those who support coin would simply be able to learn more about it and
> those who don't would still be able to participate.
> In addition to matching the reality Coin is also very easily
> integratable in other architectures, like Muji, since any participant
> can act as a proxy between the two.
More information about the Jingle