Michal 'vorner' Vaner wrote:
> 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
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.
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
problem
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
Don't we have 'jdev' list for this kind of discussion?
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, e
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
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 are
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, Rober
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:
> >>>
Robert Quattlebaum wrote:
>
> 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
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
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 the
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 in
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 reg
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,
>>
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
>>
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
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
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
> > th
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 w
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
cent
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
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.
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 "J
On Wed, 30 Jan 2008, 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 engin
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 tra
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
> cen
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 f
29 matches
Mail list logo
