Robert Quattlebaum wrote: > 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.
I don't see why that is the case. Could you expand on your reasoning? > 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. Why is it not possible for a plugin to register for Jingle-related events based on the application type? Once a plugin receives such an event, it can then register for Jingle-related events based on the session ID. So for example if a session starts out as a voice chat but one of the parties adds video via a content-modify, the video plugin can learn of the content-modify, flag the session as now of interest based on the session ID, and register for events related to that session. I freely admit that I'm not a client developer, but that approach seems eminently reasonable to me. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
