xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bau" <david....@bea.com>
Subject Re: V2 store
Date Fri, 26 Sep 2003 23:05:35 GMT
Pcal writes:
> I'm not sure I agree that large payloads do necessarily lead us to lazy
object creation.  In many (most?) cases, large payloads are large because
they contain big chunks of base64 data, and those can be dealt with
out-of-band.

Agreed, big base64 seems like it should be special-cased if you're going
straight from parser->unmarshaller or marshaller->outputter.  We should
build awareness of large base64 blobs into our fast lossy binding framework.

I'm not convinced blobs are what "large data" means for most people.
Anecdotally there are indeed folks with large numbers of rows of data rather
than just blobs that are large.  Just had a (gee fun work ;-) dinner sitting
next to somebody in the pharma IT business who told me all about their
many-rows-of-data.  A single regulatory filing, which is basically a single
atomic transaction, when printed out (as is sometimes required by law),
weighs many many tons and fills an entire tractor-trailer.  They're
transmitting things like tables of data for millions of drug-trial data
points at once.

Pcal writes:
> And in the case where someone really does have to bite off 20GB of
structured XML data at once, I have to wonder if they aren't better served
by writing directly to an API like 173.

Maybe; but maybe it's possible to make it easier too, and imho worth some
thinking.  Seems a shame to have to rewrite your app when some parameter
(like size of message) evolves.

David


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


Mime
View raw message