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: [EMAIL PROTECTED]
eMail: [EMAIL PROTECTED]
www: http://www.deepdarc.com/
