[Standards] Jingle "implementability"

[Robert Quattlebaum]

On Jan 31, 2008, at 2:20 AM, Lauri Kaila wrote:

> 2008/1/31, Michal 'vorner' Vaner <vorner at ucw.cz>:
>> Hello
>>
>> On Wed, Jan 30, 2008 at 05:53:21PM -0800, Robert Quattlebaum wrote:
>>> But the truth is that all of that complexity isn't even necessary,  
>>> as long
>>> as the XMPP client daemon can know where to route any individual  
>>> stanza. If
>>> there was some sort if information in all of the jingle stanzas  
>>> which
>>> identifies which jingle service it was intended for, then this  
>>> problem is
>>> solved. With that in place, individual processes can register for  
>>> the
>>> jingle stanzas related to them.
>>
>> Why couldn't it know now? If you are unable to filter/register by  
>> other
>> criteries than just the namespace of toplevel child, then you will  
>> find
>> problems elsewhere, too.
>
> If you are saying that there can be stand-alone plugins for
> audio/video/file transfer that don't use a common Jingle
> service/plugin/whatever in the nested way, they should be friendly to
> each other. At least, the session ids must not collide.

Session ID colisions are an easy problem to solve, if it's even a  
problem in the first place.

> A more tricky
> case to handle is multiple session types in one session when more than
> one plugin would be involved. I guess centralized handling of all
> 0166-level jingle would server fit better to that scenario.

You are correct. What I was describing cannot handle, for example,  
having an AV chat in the same session as jingle whiteboard, unless  
those capabilities were implemented into the same process/plug-in.

> Using some sort of IPC interface at some level is a needed unless it's
> ok to run all whiteboarding/videoconference/IM/etc. in the same
> application. There are many other options than the mentioned RPC:
> pipes, sockets, files, signals, shared memory, messages, dbus,
> depending on the operating system.

When I said RPC, I meant IPC. Sorry for the confusion.

> Anyway, the stricter the features are in their own namespaces, the
> easier they go into plugins. As an exmple of a difficult feature in
> this sense, XEP-0184 (message receipts) has it's own namespace, but
> also uses id-attribute of jabber:client's message element. So if the
> receipts would be implemented as a plugin on top of plain IM, it would
> require more code than if the id would be inside urn:xmpp:receipts.

Well, at least receipts are in message stanzas. Message stanzas could  
conceptually be routed to multiple plug-ins without too much problems.  
It's the IQ stanzas that MUST only be routed to one plug-in.


__________________
Robert Quattlebaum
Jabber: darco at deepdarc.com
eMail:  darco at deepdarc.com
www:    http://www.deepdarc.com/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20080131/a20d569a/attachment.htm