[Home] [By Thread] [By Date] [Recent Entries]
"Stephen D. Williams" wrote: > I agree. I feel they can be solved with a similar solution in at least some circumstances. > Rather there are some straightforward ways to acheive compression that actually make > efficiency worse while some solutions for efficiency also make compression easier. > > In fact there are a number of levels you could go with compression: > > optional gzip/bzip2 possibly preceded by: For small to medium size streams will the gzip/bzip2 step probably take longer time to complete than the savings in communications time. Of cource this also depends on the network speed. > > Dictionary compression (various forms of building a list of commonly used terms or all terms > in the current document/stream or some combination) This is probably the best first action to take when needing to compress a ML stream. Its also possible to combine Dictionaries with "Sessions". ie: two communication nodes could establish a Session which contains pre negotiated Dictionaries, which means that Dictionary content have to be sent over the wire only once. All "Packets" thereafter references the dictionaries. This is what I do in FML , however I have no estimates of how much space is actualy saved. /Anders -- /_/_/_/_/_/_/_/_/_/_/_/_/_/_/ / Financial Toolsmiths AB / / Anders W. Tell / /_/_/_/_/_/_/_/_/_/_/_/_/_/_/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|

Cart



