[Standards-JIG] changes to JEP-0138 (Stream Compression)?

Brian Raymond brian.raymond at je.jfcom.mil
Mon Mar 28 19:55:55 UTC 2005


I took a look at the features list again for Ejabberd based on a couple of
questions about JEP-0138. It looks like I need to read better next time
because it has a "-" not a "+" beside it so it's not currently supported
after all.

- Brian

On 3/28/05 2:06 PM, "Brian Raymond" <brian.raymond at je.jfcom.mil> wrote:

> I came into this late but didn't an implementation listed in the thread so I
> wanted to pass along the fact that Ejabberd calls out support for JEP-0138.
> I'm running it currently because I wanted to run some tests with live
> conversations to see the ratio I can get over time.
> 
> It turns out from some tests of XMPP dumps outside of the server that zlib
> actually makes a pretty good showing against some XML specific algorithms.
> I've been looking at it because the CPU cost to the server is much less then
> some of the others methods being kicked around for compressed XML.
> 
> If anyone else has any input on their experience with different algorithms
> please share.
> 
> - Brian 
> 
> 
> On 3/28/05 1:15 PM, "Joe Hildebrand" <hildjj at gmail.com> wrote:
> 
>> I'd be happy to add feature negotiation, if I could think of a use
>> case to write examples for.  If we can't find a concrete example, then
>> the negotiation can be handled on a per-compression-scheme basis, and
>> specified in the spec for that compression scheme.
>> 
>> 
>> On Sun, 27 Mar 2005 17:52:59 +0200, Tijl Houtbeckers
>> <thoutbeckers at splendo.com> wrote:
>>> On Sun, 27 Mar 2005 17:47:35 +0200, Stephen Pendleton
>>> <spendleton at movsoftware.com> wrote:
>>> 
>>>> 
>>>>>> Point taken about zlib. However the overall issue is that the current
>>>>>> proposal limits the implementation to zlib. Perhaps the JEP could be
>>>>>> rewritten to be more flexible. At this point though I would be willing
>>>>>> to test against any server implementation that is out there. Maybe zlib
>>>> is
>>>>>> the
>>>>>> only choice we need. If anyone has added this to a server please let me
>>>>>> know.
>>>> 
>>>>> You can just add other <method>s can't you? I expect to see
>>>>> implementations for XML specific compression or encoding in the future
>>>>> as
>>>>> well. They'd work with this too...
>>>> 
>>>> I suppose you could add other methods. It does say this in the JEP,
>>>> which I
>>>> missed, presumably by adding other <method> stanzas:
>>>> 
>>>> <stream:features>
>>>>   <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
>>>>   <compression xmlns='http://jabber.org/features/compress'>
>>>>     <method>zlib</method>
>>>>     <method>foozip</method>
>>>>   </compression>
>>>> </stream:features>
>>>> 
>>>> Now my only real issue is that if the future compression methods used
>>>> require parameters, or further negotiation, then the current JEP isn't
>>>> flexible enough to handle them. However I can't think of any that do - so
>>>> that may not be an issue.
>>> 
>>> You could either put the parameter in "method" name as you orginally
>>> suggested. You also do (yet another) stream renegotiation, as described in
>>> the JEP for such a new method. Perhaps a generic way of using FNEG could
>>> be described in such a JEP as well.
>>> _______________________________________________
>>> Standards-JIG mailing list
>>> Standards-JIG at jabber.org
>>> http://mail.jabber.org/mailman/listinfo/standards-jig
>>> 
>> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mail.jabber.org/mailman/listinfo/standards-jig



More information about the Standards mailing list