Re: [Standards] Jingle implementability
Hello
On Fri, Feb 01, 2008 at 04:50:08PM -0800, Robert Quattlebaum wrote:
On Feb 1, 2008, at 1:14 AM, Maciek Niedzielski wrote:
Stanza router could pipeline jingle stanzas through all jingle plugins.
Since a plugin tracks state, etc, it knows if it is interested in this
stanza or not. So if it wants the stanza, stanza gets eaten, else
app-level stanza router tries to pass it to next plugin, etc.
While such a model works well for apps with plug-ins in the same process as
the app, it does not work as well if your plug-ins are in different
processes--because it would be a blocking API.
Why? The router sends the stanza to the first plugin and stops blocking
-- lets it process it. After a while, the first plugin sends the stanza
back with note I do not want this, give it to someone else -- as any
other message from the plugin.
--
do { goto Water; } while( !tryBreakOffTheEar() );
Michal 'vorner' Vaner
Re: [Standards] Jingle implementability
Robert Quattlebaum pisze: On Jan 31, 2008, at 1:10 AM, Michal 'vorner' Vaner wrote: 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 the app-level stanza router was stateful (ie: keeping track of which session ID's were associated with each jingle app type), then yes, it could know. However, there appears to be no way to do this in a stateless fashion. Stanza router could pipeline jingle stanzas through all jingle plugins. Since a plugin tracks state, etc, it knows if it is interested in this stanza or not. So if it wants the stanza, stanza gets eaten, else app-level stanza router tries to pass it to next plugin, etc. -- Maciek
Re: [Standards] Jingle implementability
Maciek Niedzielski pisze: Stanza router could pipeline jingle stanzas through all jingle plugins. Since a plugin tracks state, etc, it knows if it is interested in this stanza or not. So if it wants the stanza, stanza gets eaten, else app-level stanza router tries to pass it to next plugin, etc. Moreover, a plugin framework that allows passing one stanza through many plugins is more powerful than plugin-per-namespace, etc. For example, you have a pipeline like this: Spam filter (all stanzas go through it, some are stopped) - History (writes all messages to history files) - Popups - ... -- Maciek
Re: [Standards] Jingle implementability
On Feb 1, 2008, at 1:14 AM, Maciek Niedzielski wrote: Robert Quattlebaum pisze: On Jan 31, 2008, at 1:10 AM, Michal 'vorner' Vaner wrote: 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 the app-level stanza router was stateful (ie: keeping track of which session ID's were associated with each jingle app type), then yes, it could know. However, there appears to be no way to do this in a stateless fashion. Stanza router could pipeline jingle stanzas through all jingle plugins. Since a plugin tracks state, etc, it knows if it is interested in this stanza or not. So if it wants the stanza, stanza gets eaten, else app-level stanza router tries to pass it to next plugin, etc. While such a model works well for apps with plug-ins in the same process as the app, it does not work as well if your plug-ins are in different processes--because it would be a blocking API. __ Robert Quattlebaum Jabber: [EMAIL PROTECTED] eMail: [EMAIL PROTECTED] www:http://www.deepdarc.com/
Re: [Standards] Jingle implementability
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
Re: [Standards] Jingle implementability
Robert Quattlebaum wrote: On Jan 30, 2008, at 9:14 PM, Peter Saint-Andre wrote: 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. It requires that the app maintain a state for which session-id's are associated with each plug-in. Doable, but fragile. So what exactly do you propose to overcome this hurdle? I didn't quite grok your previous suggestion. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Jingle implementability
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
Re: [Standards] Jingle implementability
On Jan 31, 2008, at 9:58 AM, Peter Saint-Andre wrote: Robert Quattlebaum wrote: On Jan 30, 2008, at 9:14 PM, Peter Saint-Andre wrote: 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. It requires that the app maintain a state for which session-id's are associated with each plug-in. Doable, but fragile. So what exactly do you propose to overcome this hurdle? I didn't quite grok your previous suggestion. I was originally suggesting appending some sort of attribute which would describe the content/session type to the jingle element, which would be there for all jingle states. This way, all jingle stanzas could be routed to the appropriate process or plug-in in a stateless manner. But, as Lauri pointed out, in the case where you have multiple session types in a single jingle session, the situation becomes ambiguous. __ Robert Quattlebaum Jabber: [EMAIL PROTECTED] eMail: [EMAIL PROTECTED] www:http://www.deepdarc.com/
Re: [Standards] Jingle implementability
On Jan 31, 2008, at 10:08 AM, Peter Saint-Andre wrote: How stanzas are handled by an internal plugin architecture is not part of the specifications for the wire protocol, nor should it be. Oh of course not, but practically you will run into problems if you have more than one reply to an incoming IQ. The only case where it would be reasonable to send an incoming IQ to multiple plug-ins is if all but one of the plug-ins are only observing and will never reply. __ Robert Quattlebaum Jabber: [EMAIL PROTECTED] eMail: [EMAIL PROTECTED] www:http://www.deepdarc.com/
Re: [Standards] Jingle implementability
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/
Re: [Standards] Jingle implementability
On Jan 31, 2008, at 10:08 AM, Peter Saint-Andre wrote: We can specify that a session ID must be a UUID. I think that's a good idea. While I think using UUID's in general is a great idea, just keep in mind that traditional UUID calculation implementations have security concerns because they leak the MAC address of the primary network card. If you are going to explicitly encourage the use of UUID's, I think you should explicitly recommend against using UUID generation methods which would leak such information. __ Robert Quattlebaum Jabber: [EMAIL PROTECTED] eMail: [EMAIL PROTECTED] www:http://www.deepdarc.com/
Re: [Standards] Jingle implementability
On Thursday 31 January 2008 10:08 am, Peter Saint-Andre wrote: 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. UUIDs aren't necessary here, just as they aren't necessary in stanza ids. If the problem is that multiple plugins might generate ids that conflict, then that's more of a local implementation problem than a wire protocol problem. Have your plugins ask the app framework for a unique id (which could very well just be a UUID, but that's an implementation choice). -Justin
Re: [Standards] Jingle implementability
Justin Karneges wrote: On Thursday 31 January 2008 10:08 am, Peter Saint-Andre wrote: 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. UUIDs aren't necessary here, just as they aren't necessary in stanza ids. If the problem is that multiple plugins might generate ids that conflict, then that's more of a local implementation problem than a wire protocol problem. Have your plugins ask the app framework for a unique id (which could very well just be a UUID, but that's an implementation choice). Well, we might recommend making the sid a UUID to avoid collisions. I don't see collisions as likely, but they are possible. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] Jingle implementability
Here is some anonymous feedback I received in an IM conversation today: ** 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. Conceptually, file transfer should be separate from audio chat, but according to the spec they both are Jingle stanzas. This makes it impossible to have more than one Jingle engine. To really understand this problem one needs to think about how routing would work in an app itself. Plug-ins would conceptually tune into certain stanzas by namespace, id value, or source field. Since there is no way to differentiate file transfer Jingle stanzas from audio chat Jingle stanzas by looking at the namespace, you would have to move all of the Jingle logic out of the plug-in and into the app. By keeping the Jingle logic in the plug-in, you greatly reduce the complexity of the plug-in API. ** Comments are welcome. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Jingle implementability
On Wed, 2008-01-30 at 19:16 +, 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.
Re: [Standards] Jingle implementability
On Wed, 2008-01-30 at 12:08 -0700, Peter Saint-Andre wrote: Here is some anonymous feedback I received in an IM conversation today: ** 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. Conceptually, file transfer should be separate from audio chat, but according to the spec they both are Jingle stanzas. This makes it impossible to have more than one Jingle engine. To really understand this problem one needs to think about how routing would work in an app itself. Plug-ins would conceptually tune into certain stanzas by namespace, id value, or source field. Since there is no way to differentiate file transfer Jingle stanzas from audio chat Jingle stanzas by looking at the namespace, you would have to move all of the Jingle logic out of the plug-in and into the app. By keeping the Jingle logic in the plug-in, you greatly reduce the complexity of the plug-in API. Why not have a Jingle plugin, and AV Chat and File Transfer could require its services?
Re: [Standards] Jingle implementability
On Wed, 2008-01-30 at 17:53 -0800, Robert Quattlebaum wrote: 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. The Jingle process could itself have plugins (subprocesses again) to handle a/v or file transfer or whatever. Presumably this subprocess plugin architecture does not use blocking RPC. If it does, you have bigger problems; for instance, you can't do two file transfers at once.
Re: [Standards] Jingle implementability
On Jan 30, 2008, at 6:08 PM, Greg Hudson wrote: On Wed, 2008-01-30 at 17:53 -0800, Robert Quattlebaum wrote: 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. The Jingle process could itself have plugins (subprocesses again) to handle a/v or file transfer or whatever. Sounds like you are suggesting an RPC API for Jingle, which would be much more complex to implement than just RPC for XMPP alone. The need for all of that complexity would be completely eliminated with a small addition to the existing protocol. __ Robert Quattlebaum Jabber: [EMAIL PROTECTED] eMail: [EMAIL PROTECTED] www:http://www.deepdarc.com/
Re: [Standards] Jingle implementability
Robert Quattlebaum wrote: On Jan 30, 2008, at 11:22 AM, Greg Hudson wrote: On Wed, 2008-01-30 at 19:16 +, 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
