On 12 Feb 2012, at 01:03, George Shuklin wrote:
...but sorry, why do you use a richfat and plumby Java
backend? There are a lot of smaller, ressource efficient,
incomplex and easier to handle open source technologies -
even full oo - available to build such a HTML management
front- and even backend?
We agree that in comparison to
xm/xl/xe, running a Java stack might seem to be a bit on
the heavy side. Yet we'd like to note that our back-end is
nothing like Tomcat or Glassfish, it contains only the
bare minimum needed to do its work.
To
elaborate choosing Java for our back-end:
- Java
applications can be deployed on a wide variety of
operating systems, if not all.
-
Eventually the back-end will also be orchestrating pools
or clusters.
- The
back-end parses responses and shrinks updates down to only
the bare minimum, limiting bandwidth use by the front-end.
- The
back-end allows access to your servers over a single
TCP/IP port, the Xen-API will not be publicly exposed.
- Again
we’re not running a whole Java EE stack, the front-end is
a webapp that lives on its own and communicates with the
backend over a WebSocket connection.
-
Coupled with Cassandra, the back-end is the only thing
that needs to be run (one single instance), for any number
of hosts.
I'm very against Java. After Oracle license change sun-jre package
was forced to be removed from the most distros. Right now Oracle
does not properly supports any dpkg (deb) based Linux distrubition,
providing only RPMs and some creepy tarball. This actually means
'very bad linux support'. And if we looks how Oracle do business we
can see no future for nice multiplatform support. Yes, there is
open-source implementation for JRE, but it still uncomplete, and,
again, resistance to publish opensource code for certification is
looking ugly.
Oracle didn't make a very good first impression in FOSS land, that's true. But there are a few things you should know about the Java situation in relation to Oracle: - The OpenJDK project now carries the reference implementation for Java, adapted by Oracle for use in their own products. So one can safely assume it's quite complete and well-tested. - Sure the community maintained builds might not be Oracle supported, but I'd argue that isn't much of a necessity anyway; even for production. The open source builds run just fine (I'm talking about my experience here). - The TCK license allows running the JCK for the OpenJDK code.
So using a 'half-opened' open-source solution, where specification
is controlled by not-very-opensource-friendly company for new
open-source product is really bad idea.
The specification is controlled by the Executive Committee ( http://jcp.org/en/participation/committee). Sure, Oracle might be a major influence, but saying they integrally control the specification is wrong. And, by all means, cut Oracle some slack, their attitude towards open-source was and still is improving.
HTML5 is much more open standard, so using html5 is more proper
solution.
... OK, let's forget Linux. Looks at windows. IE will supports HTML5
out of box. And future is looking promising. And how about Java?
Yes, you need to download it, install is separately, it starts to
nagging about updates, and it does not supports for windows system
updates, so you need to update it manually. Again, comparation Java
VS HTML5 is not toward Java.
It's not one versus the other, it's HTML5 working together with a Java backend (rather lovely, I might add).
|
