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. 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. 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. 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. -lauri
