[Standards-JIG] JEP-0060: Comments on latest draft.
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
>>>> currently (Windows Mobile, PocketPC, Smartphones, etc). I am not sure
>>>> 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
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'
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