|My only point was to point out that there are areas where XML transmission
|of data is not appropriate. The concept of a web OS, put forth by Marc as
|the initial reply to this thread, seemed to imply that memory
|would be moved
|around from JVM to JVM, across the "Web OS", seamlessly and without
|knowledge or care by the application programmers.
Just for the record,
I am not dead yet, so don't go around putting "interpretations" in my mouth.
In fact those that come to the training know how I feel about "transparency"
of object location, I dedicate about an hour to these problems. Object
transparency is a lot of boloney.
It is not achieving object transparency that is difficult in a language
(corba/rmi/rpc old stuff) it is the *efficient* real world implementation of
the distributed applications that is hard that is REAL architecture the rest
is "wee-wee" touching by so called "architects".
That is what this is about. Give me an Intel over a Microsoft, any time.
marcf
|out that this is only appropriate for certain types of messages.
|Namely, if
|messages are sufficiently large, as with seismic data in my case, or if the
|bottleneck lies with network latency, this concept of the Web OS is not
|appropriate. Of course, JBoss' pervasive use of proxies allow us to omit
|the overhead of the network if both sides of the app are running within the
|same VM. This is nice.
|
|Please don't think of XML-based messaging as the silver bullet for
|a network
|OS. If this is the case, I'll have to look elsewhere for solutions. That
|said, XML-based messaging is sufficient for most cases, although I would
|strongly disagree with your 99.999% figure.
|
|-dan
|
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of James
|Cook
|Sent: Monday, August 13, 2001 7:41 PM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] what is webOS?
|
|
|> -----Original Message-----
|> From: [EMAIL PROTECTED]
|> [mailto:[EMAIL PROTECTED]]On Behalf Of Dain
|> Sundstrom
|
|> IMHO, for 99.999% of uses an XML over a zipped HTTP stream will be
|> reasonable.
|
|I agree. We have seen 50% improvements in speed of large result
|sets that is
|gzipped before transmission. This is accomplished by employing a servlet
|filter that checks the content-length (and content-type) prior to
|transmission. If it is over a particular length, we zip it. Browsers
|automatically handle the de-compression.
|
|
|> > From: "Dan - Blue Lotus Software" <[EMAIL PROTECTED]>
|> > Sorry. Zipped files were still excessively large. You don't
|> want to take
|> a
|> > 600GB survey and turn it into a 2 TB data set. That wouldn't fit on
|> > available disk space. And data access, consisting of
|uncompressing XML,
|> > then parsing it, would be unacceptable for data volumes this big.
|
|Certainly you wouldn't want to marshall such a structure under any
|circumstances. At least not in an interactive program.
|
|One thing that may be interesting for people involved in
|compression of XML.
|We know that LZW will recognize byte patterns and replace them with a
|smaller series of bits. I wonder how effective standard ZIP compression on
|XML files is compared with a slightly more intelligent type.
|
|A more intelligent compression would not simply scan characters
|sequentially
|looking for patterns, but rather it would parse out the tags prior to
|compression. These tags (arguably the most horrendous contributors to XML
|bloat) can be effectively compressed to nothing. In fact, all of
|the tags in
|a very large DTD can be compressed to less than one byte each.
|
|I would think that significant gains in compression could be achieved over
|standard ZIP compression.
|
|jim
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
