Stuart Roebuck wrote:
> 
> Well, I have to say that I went for Cocoon primarily because it ran
> everywhere and because Java is (in my opinion) much easier to maintain - I
> used to code primarily in C and C++. I realised there would be a trade-off
> in speed to some extent, but to me the trade off is well worth it.

To make things clear: right before switching to java, I was writing 3D
engines with Federico and Pier in pure x86 assembly, hand-optimized for
the dual pipeline of the Pentium processor.

3d hardware accelleration killed us dreams and our software.

I turned to java by desperation in order to choose the higher possible
hardware abstraction ever, something that hardware updates would have
never changed under my feet (or make my work instantly obsolete).

> We are developing on Mac OS X and deploying on FreeBSD, and we have no
> problems at all with WORA.

Yeah, same here, but did you try Cocoon under Kaffe? or any other JVM
which is not derived straight from Sun's code?
 
> Whilst I have no problem with the idea of allowing JNI based 'plug-ins',
> it would be a very sad day if work spent on making the Java code run
> efficiently was pushed aside in favor of optimizing C or C++ code on
> particular platforms (probably Windows and Linux at the moment).

I totally agree here and don't be concerned: I won't leave the safe and
warm bytecode to mean and fragile native code until I'm perfectly sure
of what I'm doing.

> I appreciate the provocative nature of this email, but I also appreciate
> that there is a big unexplained basis for most of it - the first paragraph.
> 
> Could you explain why you have come to the conclusion that WORA is as much
> a problem with Java as with any other programming language in the world?
> 
> It certainly isn't my experience.

People, in case you didn't realize, Sun needs to make money out of Java
because their big iron doesn't sell like before.

WORA works because the only decent JVM is Sun's (and Sun's clones, like
IBM's or Apple's) and Sun has an viral agreement that says that every
modification you do, you have to give the code (and the right to use!
patent included!) back to Sun.

But what if Sun closes down on Java open-ness?

What if we have to use different implementations of the JVM?

You can kiss WORA goodbye and start spending your money on 'official'
java JVMs.

Stating that Java is good for WORA is like stating that x86 assembly is
good for WORA in an world where intel is a monopolist and gives away its
chips for free.

How long do you think Sun can keep the JVM free for everyone?

Or worse: what if Sun, close to bankrupcy, sells out its java division
to some company which is much more solid on software marketing
(somewhere around redmond, anyone?)

Sure, you can count on me writing my own JVM before giving up, but
that's not the point. Java WORA works, but it's fake and it's still
built on new-economy's sand.
 
> With regard to optimizing cocoon - I'd guess that caching the results of
> database access would have a massive impact on the performance of the kind
> of sitemaps we are working on.  Most of the pages are always the same
> except on the relatively rare occassions when the data has changed. But,
> at the moment many pages aggregate from four or five sources based on
> database data and the data is checked every single time and hardly
> anything is cached: so all the transforms have to be repeated.  I'm sure
> that having some simple mapping for each database table indicating when it
> was last written to would be sufficient to enable caching that would
> ensure that most pages could be reproduced directly from cache, possibly
> reducing processing time by 9/10 or more!

see my comment on xindice-dev where I state exactly this and suggest to
move this into the #1 priority for their effort.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<[EMAIL PROTECTED]>                             Friedrich Nietzsche
--------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to