Justin Karneges wrote: > 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).
Well, we might recommend making the sid a UUID to avoid collisions. I don't see collisions as likely, but they are possible. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
