AW: [Members] Stream compression (JEP-138) and notification of failureor success

Alexander Gnauck gnauck at ag-software.de
Wed Jan 11 11:03:18 CST 2006


<proceed/> sounds good to me too.
But i don't like identical tagnames in different namespaces :-(

Alex
 

> -----Ursprüngliche Nachricht-----
> Von: members-bounces at jabber.org 
> [mailto:members-bounces at jabber.org] Im Auftrag von Sebastiaan Deckers
> Gesendet: Mittwoch, 11. Januar 2006 17:46
> An: JSF members discussion list
> Betreff: Re: [Members] Stream compression (JEP-138) and 
> notification of failureor success
> 
> I agree with Gato.
> 
> One suggestion: change <compressed/> to <proceed/> so that 
> developers understand this behaviour is like with TLS negotiation.
> Clarifying the wording of the JEP would help too.
> 
> --
> Sebastiaan
> 
> 
> 
> Gaston Dombiak wrote:
> 
> >Hey guys,
> >
> >When implementing JEP-138: Stream compression my initially 
> understanding
> >was that <compressed> was being sent by the server once he 
> was able to
> >switch to compression mode and all validations have passed (e.g.
> >compression is available, compression is not already in use, etc.).
> >However, when testing against Pandion I found that Pandion 
> was waiting
> >for the <compressed> notification to be sent before compression is
> >active. 
> >
> >The reason for that is that the client was expecting a 
> confirmation from
> >the server saying that there was no <failure> and that 
> compression can
> >be established. And if a <failure> stanza was sent to the client then
> >the client will still be able to parse it since compression 
> is still not
> >active. In other words, <compressed> is being used just like 
> <proceed>
> >in TLS.
> >
> >After chatting with Sebastiaan Deckers (author of Pandion) I 
> decided to
> >change Wildfire implementation and follow the way Pandion 
> was using it
> >since the explanation seemed logical to me. Moreover, Soapbox is also
> >following this idea. I wanted to test wildfire with Exodus 
> in order to
> >confirm that exodus is also following this approach but 
> until now I was
> >not able to obtain a binary version of Exodus that supports stream
> >compression.
> >
> >Since we now have 2 servers and 1 confirmed client that are using
> ><compressed> as <proceed> in TLS, I was thinking that we 
> might need to
> >make a few small changes to the JEP. We would need to change
> ><compressed> to <compress> and also make it more clear that 
> <compress>
> >should be sent before compression is active and after all validations
> >have passed (i.e. no <failure>)
> >
> >What do you think?
> >
> >Regards,
> >
> >  -- Gato
> >
> 



More information about the Members mailing list