Only that the cost of electricity and
taxes for the server farms will push the private subnet systems service vendors
to look around for cheaper systems just as you say. Scaling up
systems like SL may become too expensive. One wonders if the peer-to-peer
VR systems like Croquet and the client-side systems with proposed network
sensors are the better bet. Not all decisions are driven by the technical
considerations of performance. Thermal costs are not friendly to the
growth of the web without some serious rethinking of server-side systems.
len
From: Ian Graham
[mailto:ian.graham@u...]
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
Cart
