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. >> 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. Says who? How stanzas are handled by an internal plugin architecture is not part of the specifications for the wire protocol, nor should it be. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
