On Jan 30, 2008, at 11:22 AM, Greg Hudson wrote:
On Wed, 2008-01-30 at 19:16 +0000, Alexander Jones wrote:
I have a few implementation observations with respect to Jingle. The
current implementation really requires all Jingle stuff to be
managed
centrally in an app. For example, you need a "Jingle engine" that
things
like file transfer and audio chat need to register with. This is
problematic if you are implementing a Jabber client where all of the
features are plug-ins.
Why not have a Jingle plugin, and AV Chat and File Transfer could
require its services?
Agreed. Reimplementing Jingle in each of the functional plugins seems
like the wrong answer; having some kind of nested plugin structure
would
be better.
What if these plug-ins are actually separate processes? Imagine if you
were using some sort of XMPP client daemon, for example. In such a
setup, you would have separate processes for file transfer, audio/
video chat, roster, etc. With how Jingle is currently specified, only
one process would be allowed to do Jingle stuff at a time. So you
could video chat, but not while being able to do file transfers. You
could use file transfer, but not be able to do video chat. One
possible solution would be to add a complex RPC for handling inter-
process jingle stuff, but that really sucks. It would be much more
complicated than the RPC for the XMPP stream itself.
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.
There is nothing stopping these processes from sharing the same Jingle
implementation. They can use a shared library and that would work just
fine.
Adding this information to the stanzas would not stop a centralized
jingle implementation in an app, if the app author wants to do things
that way. Adding this information would just make implementation much
more flexible.
__________________
Robert Quattlebaum
Jabber: [EMAIL PROTECTED]
eMail: [EMAIL PROTECTED]
www: http://www.deepdarc.com/
