XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Is it time for the binary XML permathread to start up again?

Alessandro Trigila writes:

> Fast Infoset doesn't try to be extremely tightly coded.  We tried to
> find a good balance between ease of implementation, 
> encoding/decoding speed, and compactness.  So there is still room 
> for gzip to remove some of the residual redundancy.

OK, that makes a lot of sense.  Still, one has to be careful.  There's a 
line of reasoning that goes:

a) Fast Infoset is only secondarily about compactness; it's about speed. 
That's why there's still redundancy that gzip can find.
b) If we're willing to take the result of what we computed quickly and run 
it through gzip, we can make it small after all, but then it will be 
slower.

That's not to say that in the 2dimensional space vs. time plane you might 
not wind up for some purpose at a happy compromise by running FI and gzip, 
but it's far from obvious in advance that the two are complementing rather 
than diluting each others' best qualities in general.   Would I be right 
in guessing that you shouldn't even consider doing the gzip step if you're 
interested mainly in reducing CPU overhead?

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS