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