[
Lists Home |
Date Index |
Thread Index
]
What David Megginson posted earlier is pertinent:
"So, really, these tools are suitable only for writing short XML
configuration files or faqs, not books or manuals. I'm guessing that the
problem is an object explosion: the programs probably use Java objects for
everything, instead of optimizing internal storage with arrays and building
objects only on demand (it's the same kind of problem that shows up with
naively-written Java-based DOM libraries)."
Cheap resources invite exploitation. Then costs rise.
Interesting problem: what limits production
and keeps the cost of software within some range? Offtopic, but...
Even when resources are cheap, discipline is worthy. This is
when it is most worthy, not with regard to short term
economics, but long term health that is harder to come by as
any system ages and increases its interdependencies.
As we emphasize scripting solutions for
building applications, the object costs bite harder. What
happens to servers as we thin out the client, for example,
and give the server lots and lots of middleware objects
from multiple applications from multiple development teams?
We offload the problem to the hardware in the form of
server farms and these in turn, draw heavily on the power grid.
At some point, a cascading failure seems inevitable.
len
From: Michael Champion [mailto:mc@xegesis.org]
That's one of the most profound questions the XML world faces, IMHO.
On the surface the answer is obvious - NO! It is cheaper to just buy
memory (maybe even for your customers!) than to spend time time/speed
optimizing code or bandwidth. But on the other hand ....
- Memory, bandwidth, and even processor speed are still precious on
mobile devices. Do you want to shut them out of your market?
Obviously that's not a consideration for Eclipse plugins :-)
- Batteries aren't covered by Moore's Law.
http://www.wired.com/wired/archive/12.04/start.html?pg=2 has a nice
rant on this subject.
- More generally, as the Wired piece implies, there's sortof a tragedy
of the commons here -- EVERYONE assumes that bandwidth/memory/power is
inexhaustible, exacerbating the problem in environments where it's a
limiting factor.
I think all this gets back to the advantages/disadvantages of
standardization we've been talking about. XML's text basis, Java's
virtual machine, Eclipse's loosely coupled architecture all have very
distinct advantages that are widely touted. They also have
disadvantages, mainly in the area of performance/resource overhead.
It's important not to oversell the advantages to people who are going
to be hurt by the disadvantages, and it's important to try to
ameliorate the disadvantages in a way that does not negate the real
advantages.
|
