I am kinda saddened that the discussion as turned to a minor point, that of
the factor at which the current technology will catch up to make
distribution of data a viable solution.
I repeat that to me the solution lays not with the XML/zip solutions as much
as it lays on the power of the bare metal under it. It is not a bandwith
issue it is a simple MIPS issue.
Let just go back to the mine, the vision "dope" is heady but not very
productive, specifically not when factions fight over sub-nodes of it where
probabilities become fuzzy.
No religion, only intra-venous technology, if possible in its purest form
please, we can handle it... yeah right! just don't overdose kids! Go work
now, make it real, ;-)
Love,
marcf
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Dan -
|Blue Lotus Software
|Sent: Monday, August 13, 2001 5:04 PM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] what is webOS?
|
|
|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. I only intended to point
|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
