RE: Compression (was RE: COMPLEXITY BIG ISSUE)

[David Burdett <david.burdett@commerceone.com>]

I agree but you could achieve the same result by splitting up the original
file and sending each piece separately using the ideas of "Message Sequence
Number" that John Ibbotson described in the conference call yesterday.

Anyway, ultimately you might find that even a zipped file is too big. Then
you have no option but to split it up and send each part separately.

Regards

David

-----Original Message-----
From: Dick Brooks [mailto:dick@8760.com]
Sent: Friday, March 10, 2000 2:52 PM
To: David Burdett; Ebxml
Cc: ebXML Architecture (E-mail)
Subject: RE: Compression (was RE: COMPLEXITY BIG ISSUE)


David,

You are correct in stating that communication hardware will perform
compression, and this certainly has a
positive impact on the time required to move the data across "the line".
However, there are times when compression
is needed at higher levels. For example, lots of e-mail servers have MAXIMUM
SIZE limits. Larger files (that have been compressed) can be sent through
e-mail because their compressed size fits under the max size limitation.

I don't think the issue exists with HTTP (yet), but it sure is a problem
with e-mail.

Dick Brooks
http://www.8760.com/

-----Original Message-----
From: owner-ebxml-transport@lists.oasis-open.org
[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of David
Burdett
Sent: Friday, March 10, 2000 3:20 PM
To: 'Dick Brooks'; Ebxml
Cc: ebXML Architecture (E-mail)
Subject: RE: Compression (was RE: COMPLEXITY BIG ISSUE)


I agree that compression is important. But before we go down this route can
someone tell me if the communication transport providers compress data that
is sent over the wire (literally). I know that the ordinary modems used in
PCs do.

My point is that if the compression is done at the the communication
transport level, then compressing it before it sent might be redundant and
significantly reduced benefit.

Secondly, if the space occupied on disk is a concern (whicy I doubt these
days), then using disk compression technology that already exists should
provide the answer.

Thirdly, what should you compress. I don't think you should compress the
message headers since a) their small anyway, and b) they need to be
understood before you know what to do with the message. If they are
compressed then you might have to decompress the whole message before you
can decide what to do with the message. As "deciding what to do with the
message" is the first thing you ever do. Enforced unnecessary decompression
will only increase your workload not reduce it.

Fourthly, if only the bodies of messages are candidates for compression,
then there are already simple utilities that can be used to compress data
when you need to. Do we need to specify how? For example what's the
difference between an attachment of type application/zip and
application/xml?

So let's only solve the compression problem if we have a real problem to
solve.

Regards

David

-----Original Message-----
From: Dick Brooks [mailto:dick@8760.com]
Sent: Friday, March 10, 2000 12:03 PM
To: Ebxml
Subject: FW: Compression (was RE: COMPLEXITY BIG ISSUE)


I'm forwarding this email from the Architecture list calling for ebXML to
support compression. This became an issues in some EDIINT testing also. It
makes sense to include compression in our set of requirements, especially if
payloads will be encoded using base64.

Dick Brooks
http://www.8760.com/

-----Original Message-----
From: owner-ebxml-architecture@lists.oasis-open.org
[mailto:owner-ebxml-architecture@lists.oasis-open.org]On Behalf Of
Solinsky, Jason
Sent: Wednesday, March 08, 2000 6:57 PM
To: 'Duane Nickull'; Troy R Lowe; ebXML-Architecture
Subject: Compression (was RE: COMPLEXITY BIG ISSUE)


Is there no ebXML group that is considering the use of compression in
communications? Certainly in highly structured, low entropy communications
(such as we are discussing) compression ratios can exceed 10 times.

If we plan on supporting one or more compression algorithms, we will no
longer need to trade off size for readability. Furthermore, if encryption is
used at some level in the process [as I would expect], we will almost
certainly want to compress communications immediately prior to encryption to
remove redundancy.

I apologize if this is the wrong group for this message. It is my first
ebXML post.

Jason W. Solinsky
Chief Technology Officer
USPowerSolutions

|>

Troy wrote:

Plus numeric tags will be smaller for transport.