[Standards] Jingle "implementability"

[Robert Quattlebaum]

On Jan 31, 2008, at 9:58 AM, Peter Saint-Andre wrote:

> Robert Quattlebaum wrote:
>>
>> On Jan 30, 2008, at 9:14 PM, Peter Saint-Andre wrote:
>>> Why is it not possible for a plugin to register for Jingle-related
>>> events based on the application type? Once a plugin receives such an
>>> event, it can then register for Jingle-related events based on the
>>> session ID. So for example if a session starts out as a voice chat  
>>> but
>>> one of the parties adds video via a content-modify, the video  
>>> plugin can
>>> learn of the content-modify, flag the session as now of interest  
>>> based
>>> on the session ID, and register for events related to that  
>>> session. I
>>> freely admit that I'm not a client developer, but that approach  
>>> seems
>>> eminently reasonable to me.
>>
>> It requires that the app maintain a state for which session-id's are
>> associated with each plug-in. Doable, but fragile.
>
> So what exactly do you propose to overcome this hurdle? I didn't quite
> grok your previous suggestion.


I was originally suggesting appending some sort of attribute which  
would describe the content/session type to the jingle element, which  
would be there for all jingle states. This way, all jingle stanzas  
could be routed to the appropriate process or plug-in in a stateless  
manner.

But, as Lauri pointed out, in the case where you have multiple session  
types in a single jingle session, the situation becomes ambiguous.

__________________
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/c91c14ae/attachment.htm