[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?
- From: "Len Bullard" <cbullard@hiwaay.net>
- To: <noah_mendelsohn@us.ibm.com>, "'Alessandro Triglia'" <sandro@mclink.it>
- Date: Fri, 20 Jul 2007 18:33:21 -0500
Yes.
len
Comments interspersed...
From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
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 about speed.
> GZIP is about compression
Ultimately fast vs inconveniently slow?
>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.
Yes. Hmm, object density in RAM. The CPU is not the problem. The choice
of design for the density of the objects is. RAM over rate=of-ID loads.
>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,
Perhaps when binding s collection for pre-load. I don't care if it is slow
if for the cost of syntax the feature set bound is at some distribution in
the coordinate space. IOW, how dense is the
complex/related/vector-representation of objects by proximity and rate of
motion/change.
In author space, it is the complexity of the application relationships:
objects in Ram, dull but measurable.
Markup systems cost benefits are measured by the density of consumable
relationships, ie, the possible namespaces in a wrapper hypermedia language.
Data is common. Semantic density is king.
len
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
--------------------------------------
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]