On Thursday 31 January 2008 10:08 am, Peter Saint-Andre wrote: > Robert Quattlebaum wrote: > > On Jan 31, 2008, at 2:20 AM, Lauri Kaila wrote: > >> 2008/1/31, Michal 'vorner' Vaner <[EMAIL PROTECTED]>: > >>> 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. > > We can specify that a session ID must be a UUID. I think that's a good > idea.
UUIDs aren't necessary here, just as they aren't necessary in stanza ids. If the problem is that multiple plugins might generate ids that conflict, then that's more of a local implementation problem than a wire protocol problem. Have your plugins ask the app framework for a unique id (which could very well just be a UUID, but that's an implementation choice). -Justin
