There's an interesting infrastructural and maintenance cost that may be
driving some of these decisions. For example, it is likely cheaper - in electricity and cooling costs, operations support and maintenance costs to purchase cheaper dedicated boxes than it is to implement on standard generic servers. I know that where I work now power and air condition constraints, as well as the cost of maintaining / managing the systems, is often a key driver of decisions. Typically, appliances seem to win out for things like XML routing, SSL compression, etc. Thoughts? // Ian Len Bullard wrote: I've been interested because I was an early supporter of markup for graphics. Then in VRML, it became apparent that the advantages were limited to tool reuse, the actual syntax being not attractive in that medium. Otherwise, with the growing use of real-time 3D and the development of XML-based messaging for these real-time worlds in XML, I've been wondering about the use of XML hardware accelerators on the server farms. XML in VRML was opposed bitterly based on the object model not being a match and that the syntax would slow down the application unacceptably. The first objection is true but trivial. The second turned out to be nonsense. While I've not tested the high rate of exchange issues David and others mention, I have tested the loading time using the River of Life project files. I've been building in VRML using the curly syntax for mostly legacy reasons, but I started converting pieces to X3D in the XML format using the Flux Studio 2.0 editor from Media Machines. It imports and exports X3D (and KML) flawlessly. Loading the X3D/XML into a viewer from a different vendor just to be sure there are no in-house tricks, there is NO noticeable difference to the end user. Zero. Nada. That contradicts all my expectations and predictions from the graphics experts. While I still think there is a case for a binary, it may be a lot more limited than predicted if my informal tests are any indicator, but I'm still holding out for the results from the working groups. <plugForTheGoodGuys> BTW, if real-time 3D in XML interests any reader, the Media Machines Flux Studio 2.0 3D editor is a prize-winning cherry. The features included are mind boggling for a free-for-personal-use piece of liveware. </plugForTheGoodGuys> len From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] Sent: Saturday, February 24, 2007 3:41 PM Len Bullard writes:Imagine a processor per language. Gack!Yes, Gack, as you put it. Now imagine a processor that's good at character and string manipulation, table lookup scanning, buffer manipulation, substitution, etc. and you might have something that would do well on lots of languages, XML included. A better investment than more general purpose processing cores? I have no clue at this point. I should say, I've personally never been a fan of special purpose hardware, except when either its peak or average utilization is likely to be very high (as seems to be the case with graphics chips, ethernet chips, and the like). It won't surprise me a bit if, even if XML processing is offloaded, that the offload is to general purpose cores. I'm just pointing out that the equation is changing as the relative rate of change in clock speed vs. transistor count starts to favor the latter. There will be increasing incentives to learn to do work in parallel as opposed to sequentially. Anyway, this discussion has probably gone past the point of being of interest to a crowd that gathers here mainly to discuss XML. I'm happy to wrap it up around now. 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.ph |