[Standards-JIG] JEP-0060: Comments on latest draft.

Tijl Houtbeckers thoutbeckers at splendo.com
Mon Jun 28 22:00:46 UTC 2004


On Mon, 28 Jun 2004 14:42:17 -0600, David Waite <mass at akuma.org> wrote:

>
> On Jun 28, 2004, at 2:34 PM, Tijl Houtbeckers wrote:
>
>> On Mon, 28 Jun 2004 09:18:07 +0200, Ralph Meijer  
>> <jabber.org at ralphm.ik.nu> wrote:
>>
>>> On Sun, Jun 27, 2004 at 03:03:31PM -0400, Stephen Pendleton wrote:
>>>> Just FYI: TLS compression would work, but doesn't exist on some  
>>>> platforms
>>>> currently (Windows Mobile, PocketPC, Smartphones, etc). I am not sure  
>>>> about
>>>> other non-Unix non-Win32 platforms. I have been hoping that a server
>>>> developer could offer some solution to this issue at some point.
>>>
>>> I'm confused. If TLS is not available, but other server side solutions  
>>> would be
>>> implementable (surely you'd need something on the client side as  
>>> well), why not
>>> just write a TLS implementation?
>>
>> An XML specific compression scheme could get you much better  
>> compression rates than TSL.
>
> Such as? There are no XML-specific compression schemes that I know of,

There are plenty out there, both propriety and opensource. From the top of  
my head; Xceed, milou, Xmill, XMLPPM, XML-Xpress.. I'm sure there are  
plenty I missed. I think the problem right now is more that there are too  
many ;)

There's plenty of papers on the subject too, and examples of how you can  
get much better compression. This is not just theoretical.

> let alone ones which will work on document fragments and not 'true'  
> documents.

Heh. I remember people saying this about XML parsers when they wanted to  
write a Jabber client ("so that's why I *have* to build my *own* parser,  
you see?"). Most of these solutions integrate within a normal SAX or DOM  
parser, and handle block level compression just fine. Even if they don't,  
it's not so hard to hack insert-your-fav-jabber-lib-here to spit out  
different blocks rather than one stream.

> And while they 'could' provide better compression, I doubt that the  
> difference would be significant enough to warrant requiring people to  
> write a compression algorithm impl, vs. using the readily available, or  
> perhaps even built into the (TLS) socket implementation.

It depends on what important to you. If you send big chuncks of data  
(which is far from always the case in the Jabber world) TLS will help you  
some. But TLS is no match for binary XML, dictionaries over multiple  
sessions, clever reordering of data, schema based compression and what  
not. after which you can still ofcourse apply the standard stream based  
compression methods TLS compression uses!

Trust me, when you pay for big bucks for every byte of data you send, and  
there's a way you can shave a few percent of your traffic (and you can go  
much further than TLS in that) you'll do it. I've talked with folks that  
are in just that situation and trust me; they weren't all that impressed  
by Jabber at the first glance!

Only after I explained to them that with clever compression you can get  
much less datatraffic than with standard compression methods (wich was  
still far too bulky for them) they decided to give Jabber a second look.

Ralph asked: Why not just implement TLS compression?
Answer: if compression *really* matters to you, then the alternatives are  
out there and certainly worth investigating.





More information about the Standards mailing list