Re: [Standards] UPDATED: XEP-0171 (Language Translation)
XMPP Extensions Editor wrote: > Version 0.3 of XEP-0171 (Language Translation) has been released. > > Abstract: This document defines an XMPP protocol extension for > providing language translation facilities over XMPP. It supports > human, machine, client-based, and server-based translations. > > Changelog: [See revision history] (kl/bf) > > Diff: > http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0171.xml?r1=257&r2=1649 > > > URL: http://www.xmpp.org/extensions/xep-0171.html As far as I can see, the earlier feedback regarding this spec has not yet been addressed. In particular the following issues: 1. Registering a translation provider with a server http://mail.jabber.org/pipermail/standards/2006-October/012579.html I agree with Ralph Meijer that this can be done via entity capabilities (XEP-0115): http://mail.jabber.org/pipermail/standards/2006-October/012596.html But it would be good for the spec to say that explicitly. And see also: http://mail.jabber.org/pipermail/standards/2006-October/012581.html http://mail.jabber.org/pipermail/standards/2006-October/012582.html http://mail.jabber.org/pipermail/standards/2006-October/012585.html 2. Server-requested translation http://mail.jabber.org/pipermail/standards/2006-October/012580.html I think that one aspect of Chris's feedback is handled by the switch to use of IQs, but not all aspects. What do the authors of XEP-0171 think about these issues? I'll try to complete my own detailed review soon. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
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/
[Standards] UPDATED: XEP-0171 (Language Translation)
Version 0.3 of XEP-0171 (Language Translation) has been released. Abstract: This document defines an XMPP protocol extension for providing language translation facilities over XMPP. It supports human, machine, client-based, and server-based translations. Changelog: [See revision history] (kl/bf) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0171.xml?r1=257&r2=1649 URL: http://www.xmpp.org/extensions/xep-0171.html
Re: [Standards] XEP for using XMPP as a "Enterprise Message Queue"
"Jacob Burkhart" <[EMAIL PROTECTED]> writes: > I'm looking for some suggestions (or perhaps I'm looking to write my own > XEP) for a standard way to allow XMPP to act like a message queue. Sounds like http://www.xmpp.org/extensions/xep-0142.html to me. -- Magnus JID: [EMAIL PROTECTED]
Re: [Standards] Jingle "implementability"
On Feb 1, 2008 10:47 AM, Tomasz Sterna <[EMAIL PROTECTED]> wrote: > Don't we have 'jdev' list for this kind of discussion? I think this is the appropriate list for discussing protocol implications. /K
Re: [Standards] Jingle "implementability"
Don't we have 'jdev' list for this kind of discussion?
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"
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"
Justin Karneges pisze: On Thursday 31 January 2008 10:08 am, Peter Saint-Andre wrote: Robert Quattlebaum wrote: 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 Or just make every plugin prepend id with plugin name (sth like id='jinglecall-123') -- Maciek
