[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Compression

• From: Danny Ayers <danny@p...>
• To: Xml-Dev <xml-dev@l...>
• Date: Thu, 15 Feb 2001 22:58:13 +0600

Well I never - my first 2 scenarios are covered by http 1.1 and the third
(difficult version) used by public/private key encryption.
(thanks Daniel, Jeff)

Cheers,
Danny.

<- -----Original Message-----
<- From: Danny Ayers [mailto:danny@p...]
<- Sent: 15 February 2001 17:51
<- To: Xml-Dev
<- Subject: Compression
<-
<-
<- Hi,
<- Just a thought - presumably not original.
<- Ok, big arguments against of transmitting XML in a compressed
<- binary form is
<- that we lose the standardization, and with it the ease of
<- interpretation. So
<- what about making a negotiated dialog of the transfer :
<-
<- Scenario 1 :
<-
<- A tells B (in straight XML) that it has some data for it, and it
<- knows how
<- to compress in the format specified at URI http://zip
<- B replies fine, I know know that format
<- A zips the XML and sends it
<- B unzips the file and uses the data
<-
<- Scenario 2 :
<-
<- A tells B (in straight XML) that it has some data for it, and it
<- knows how
<- to compress in the format specified at URI http://zip
<- B replies sorry, I don't know that format
<- A sends plain XML
<-
<- Now lets say that at URI http://zip there is a pointer to a
<- place that holds
<- the decompression algorithm, or a ready-compiled converter (or converters
<- for different platforms)
<-
<- Scenario 3 :
<-
<- A tells B (in straight XML) that it has some data for it, and it
<- knows how
<- to compress in the format specified at URI http://zip
<- B replies - please wait
<- B goes to the URL pointed to at http://zip, downloads and installs the
<- converter
<- B tells A, I'm ready
<- A sends binary...
<-
<- Some of this negotiation could probably be tucked into PIs.
<-
<- A harder (but quite interesting) alternative would be to have a
<- pointer on
<- http://zip  to a document specifying the (de)compression algorithm, from
<- which B could build its own native converter.
<-
<- I find the idea of compressed XML a bit lumpy, but a system like
<- this could
<- at least make it more transparent. Obviously the conversation
<- needs a bit of
<- extra bandwidth than a straight send, but this would by offset
<- in a big way
<- if there was a lot of data.
<-
<- I'm sure there are a lot of other situations outside compression
<- where such
<- a system could be used, which is why I presume the idea isn't
<- original ;-)
<-
<- Cheers,
<- Danny.
<-
<- ---
<- Danny Ayers
<- http://www.isacat.net
<-
<-
<- ------------------------------------------------------------------
<- To unsubscribe from this elist send a message with the single word
<- "unsubscribe" in the body to: xml-dev-request@l...
<-

• Follow-Ups:
  • RE: Compression
    • From: Andrew Morrow <amorrow@c...>

• References:
  • Compression
    • From: Danny Ayers <danny@p...>

• Prev by Date: RE: Compression
• Next by Date: Re: Compression
• Previous by thread: RE: Compression
• Next by thread: RE: Compression
• Index(es):
  • Date
  • Thread