Richard Davies wrote: The UK has a good crop of technology pioneers in cloud computing - for example ElasticHosts, FlexiScale, Flexiant, OnApp - and also some strong government initiatives such as G-Cloud.
We will have to see whether this kind of technical leadership converts into swift mass-market adoption or not.
The ubiquitous presence of the Internet has enabled a new software deployment
paradigm in which software applications are downloaded from the internet and run
within a Web browser, rather than being installed on each end-user's computer.
This new paradigm significantly reduces the total cost of ownership of desktop
computers in a corporate IT environment by eliminating the need to manually
deploy new versions of the software. It also makes applications more portable by
allowing users to access their programs and data remotely from any computer with
a network connection. However, despite these recent advances, several major
technical hurdles remain. One of the most difficult problems is to develop a
productive and highly interactive user interface that is widely compatible among
various clients, and that can be developed and maintained at a reasonable cost.
Today, most Web-based applications use HTML or dynamic HTML (DHTML) as means
of interacting with the user. While a user interface that relies on HTML or
DHTML is good for displaying information, it is much more limited when it comes
to data entry. This is because HTML is primarily a request-response based
screen-oriented protocol. In an HTML application a user must typically fill out
all the fields on a form before submitting the form back to the Web server for
validation. If there are any errors in the user input they are often not
detected until the entire form has been filled out. Contrast this "block-mode"
validation with the "field-mode" validation found in most desktop applications
where user input is validated on each field as it is entered. The field-mode
validation is more interactive and catches user errors sooner resulting in a
much more responsive system. Field level validation is crucial for applications
that require the user to enter a significant amount of data.
In addition to not validating the input from every field, HTML user
interfaces also usually require a complete download and re-layout of the entire
page in order to respond to any user input. This makes applications based on
HTML or DHTML very slow to use if there are many pages of data to enter. While
it is possible to work around some of these problems using very sophisticated
DHTML scripts, doing so requires stretching the capabilities of DHTML beyond the
limit that can be easily maintained.
Because of these limitations, applications built solely with dynamic HTML
often have user interfaces that are slower and more difficult to use than the
traditional client-server applications they replace. In addition, reasonably
responsive DHTML applications are often harder to maintain than many traditional
client-server applications because they usually must mix business logic with
user interface logic on the client in JavaScript.
The most promising alternative to DHTML is a Java-based client. Java can
provide a much more interactive user interface because Java clients can provide
field-level validation and can communicate with the server each time the user
enters data into a field. The server receives the new input from the client, and
responds by updating the application data on the screen. Unlike HTML or DHTML
clients, Java clients do not need to layout the entire screen in response to
each user input because Java clients can easily separate application data from
the page layout. This results in a much more responsive user input experience
because the screen is not redrawn upon input; only the application data within
the controls on the screen changes.
Java-based clients also provide more interactivity by supporting better user
interface controls such as tables that keep their column or row headers fixed
when the data is scrolled, and "tree controls" that allow the user to display
data in a collapsible hierarchy. Java clients also can more readily accommodate
multi-level menus that allow more menu-based functionality to be packed into a
smaller area on the screen. Finally, it is much easier to implement and maintain
many networked programs whose clients are written in Java rather than DHTML
because Java is a more powerful language for expressing the runtime
interactivity required on the client.
Despite these advantages, client-side Java has not gained wide acceptance.
This is because historically many browsers have had compatibility problems with
their Java implementations, and because there were too many bugs in the earlier
releases of the Java language itself. According to IDC [3]:
"While the Internet has made data and other forms of content easier to
access, the promise of being able to access and execute applications - and other
services - from anywhere remains elusive. Java is a major enabler to achieving
this promise, but legendary issues with Java, particularly on the client side,
have slowed down progress."
In addition to compatibility problems, Java clients have also had to contend
with slow downloads and relatively long start-up times. Typical user interfaces
written in Java have client-side components ranging in size from 300K to 1
megabyte, which take from 1 to 3 minutes to download over a 56K modem. While
this download only needs to occur once on most browsers because of caching, the
initial download can be severely discouraging to casual users who simply want to
display information from a Web site. In addition, the version 4 Netscape
browsers required several seconds to start Java because the Java runtime engine
was not loaded at browser startup. These problems were fixed in Netscape 6, and
were never present in Internet Explorer. However, the slow downloads and slow
Java startup time in Netscape 4 browsers gave Java clients a bad reputation for
performance. That made Java clients unacceptable for many consumer-facing
e-commerce sites where a Web page has only a few seconds to load before the
consumer's interest is lost.
Java clients are primarily appealing when the performance benefit they
provide during use outweighs the download and start-up times. This can occur
when the application is sufficiently complex that it requires considerable time
to enter the data into all the screens, or when the application is used by
dedicated users for long periods of time. The performance benefit can also
outweigh the startup time if the application is used sufficiently frequently
because the Java applet is cached by most browsers.
The use of Java clients is becoming more attractive as the Web evolves.
Initially, most Web applications were simple e-commerce shopping applications
that required little user input beyond clicking on a picture of the item to buy.
Now there are a rapidly growing number of business-related applications that are
becoming highly specialized and require more interactivity.
In addition to business based internet applications, many companies are using
the internet or a secured, internal form thereof (an intranet) to automate their
internal business processes. These business processes can be quite complex and
are typically used over a local area network where download times are shorter
and the amount of time spent using the application is longer.
Java clients will also become more attractive to consumers as consumers begin
to experience the faster downloads available with broadband network services
such as digital subscriber lines (DSL) or cable modems. A recent report on
broadband adoption shows that over 72% of US work locations and 38% of all US
households now have broadband connections to the internet[4]. On a broadband
connection of 1 megabit per second, a 1 MB Java client can be downloaded in
about 8 seconds. As more and more connections get faster, the download time for
most Java clients will be reduced below that of the accumulated "latency" delays
required to establish the many smaller connections that are typical of most of
today's DHTML-based Web pages.
The last major factor that is beginning to make client-side Java more
appealing is that Sun Microsystems has recently begun partnering with most major
PC manufacturers to get recent versions of Java pre-installed as part of their
standard software distribution. To date, Sun has announced deals with HP-Compaq
and Dell, and is in the process of working with many other major PC
manufacturers. Sun has also launched its "Java Desktop" (http://javadesktop.org)
and "Get Java" initiatives to further promote the use of Java on the client.
These initiatives will soon lead to Java being a ubiquitous part of client-side
computing once again.
Summary:
The ability to automatically download and execute programs on internet-based
client computers makes Java technology an ideal candidate for realizing the
potential benefits of the "Network Computer" in which the computer is simply a
modular networked workstation that downloads its software as-needed from the Web
and requires no setup or maintenance. However, browser compatibility problems
and the lack of high-speed internet access has historically limited the
acceptability of Java clients to dedicated intranet business applications that
require the highly interactive user interface that a Java client can deliver. As
browsers improve and broadband internet connections become more common, Java
clients promise to return to us the interactivity that we have compromised in
today's DHTML-based internet applications.
About John Kucera John Kucera is currently the chief technical officer of Asperon Corporation, a company dedicated to providing infrastructure for highly-interactive web based business applications. He holds a Ph.D. in physics from the Massachusetts Institute of Technology. Dr. Kucera spent 3 1/2 years at Oracle Corporation where he most recently was a director of user interface (UI) technology in the Customer Relations Management (CRM) Division. He was also instrumental converting Oracle's Applications from a client-server to a three-tier web based architecture allowing Oracle's ERP Applications to run over the internet.
Reader Feedback: Page 1 of 3
#31
Tim commented on 20 Apr 2004
"Developing full-featured Applets for Java, can be quite difficult. However, seeing an Applet which is indistinguishable from a local application, running full-size, inside a browser, is an amazing thing!"
While looking for car parts, I stumbled into one of those: http://www.rockauto.com/ has a online part catalog front-ended by an applet that blended very well with surrounding HTML.
With more OEMs putting Sun JREs on new computers and broadband connections that make downloading Sun JREs and larger applets, I wouldn''t count Java out quite yet on the client. However, It needs the "killer-app" that will motivate Joe and Jane Internetuser to download Sun JREs
#30
Matt commented on 3 Feb 2004
Excellent article! I have been developing Swing clients for over two years for a large scale business application. We switched from Microsoft 2-tier to N-tier using J2EE. We decided upon Swing clients for several reasons. 1) We wanted to have a consistent language on the client in the middle tier 2) We wanted the same look and feel as our existing applications. Users and our application designers are familiar with the MDI application. We did not want to reinvent existing standards. 3) JNLP(Web Start) were new but would provide the answer to reducing deployment costs. 4) A quick response for data entry was a requirement. 5) The complexity of the UI could only be done in Swing.
This project has approx. 70 developers and 50 client apps. Some VB applications still exist but once the migration is complete we will have a browser based portal which will be the center of the users job function. Report generation, alerts, and external links relevant to their business will be in the portal. The portal will contain links to the Java clients which are downloaded by JNLP that allow the users to execute their business functions. This is the future of business applications and my organization is very close to the future because of Java.
Java, Swing, and JNLP (Java Web Start) is the future. F.E. ScheduleWorld is a pure Java/Swing/JNLP Outlook replacment that is interoperable with Outlook/Exchange/Notes/etc.. over email. It''s secure, fast, free, and the server service and interoperability bridge is free as well. It''s an excellent example of why Java is the best way to go and proof that truly great applications simply can not be written with a web front-end.
#28
Chris Murphy commented on 6 Jan 2004
With more than 50% of computer manufacturers intending to put a JRE on their new machines in the future the biggest problem will come to be moving Data Objects across firewalls with some sort of a transaction layer. The objects won''t need to be distributed, but appear to be so within the context of the transaction. I think the terminology here is ''course grained''. I think that SDO (Service Data Objects) will make a contribution in this area. With SDO/JDO, will we finally be able to code to update data objects over the net as if we were writing a client/server application to a local OODB?
#27
Mohee Jarada commented on 1 Dec 2003
I agree with the author article regarding that either Java clients (SWING apps) or Java Applets can be a replacement for DHTML Web technology when internet network bandwidth is faster.
The only thing he forgot to mentioned talking about the Java Clients network communication problems like serlization and de-serialization problems of heavy java objects travelled from Java Clients to Web Java servers.
Also Microsoft had made a big mistake when they re-shaped the web technologies just for their interests and they collapesd the meaning of a platform independent concept, and just year by year creating a headache technology instead of smooth, simple and stable platform!!!!
#26
Brooks commented on 19 Nov 2003
Agreed it''s odd author didn''t mention Webstart. I''ve developed in VB desktop, asp, ColdFusion and jsp/servlets. My VB desktop applications provided extremely rapid and bullet proof data entry that only something like Flash could begin to equal in a web based app ( but I''ve had probs getting Flash apps to download and work properly) The growing power of desktops further argues for desktop apps. That said, I agree with writer who said Java was cumbersome and much faster to use, e.g., Python. Given that VB.NET and C# are much more like java than Python, I see no real advantage to going there (and also eliminating all Linux machines for your app). So, give us the concept of Webstart (with smart updates of just the parts that changed) in a language like Python with, e.g., type-ahead combo boxes and life would be lovely and my users much happier.
#25
John commented on 12 Nov 2003
Developing full-featured Applets for Java, can be quite difficult. However, seeing an Applet which is indistinguishable from a local application, running full-size, inside a browser, is an amazing thing! Unfortunately I''ve seen too many developers give up out of frustration, just before making the critical breakthrough.
To help more people realize this epiphany, I have created a small, completely free framework, hosted at the java.net website. It''s both simple and very powerful. Amongst other things, it shows how to create Applets which have all the features of a Java application, with no need to sign the codebase! (Naturally it won''t let you write to the client''s hard drive)
If you are ready to get really excited about Java again, visit:
Note: some developers have called the project ''rocket-science'' to understand, but all have agreed it is extremely simple to use. As with any technology; you don''t have to fully master it, in order to use it.
#24
LaloCeli commented on 10 Nov 2003
This article is, definately, out of date, and brings nothing new. He also forgets to mention JSP, and JavaServer Faces (JSF).
#23
Charlie Fulnecky commented on 10 Nov 2003
Having just come off of a major project using DHTML on the client I can attest to the power ... dynamic trees, tables, context menus, etc. and also the pain. The development environments are far less mature compared with those available for Java(currently using JDeveloper and Eclipse) and the poor implementation of standards makes X-browser support a nightmare. My team spent 6 months creating a web-app that used xml and xmlhttprequest objects to maintain state on the client, we built a robust framework of widgets that included movable windows, dynamic trees and tables and full featured menus/context menus built on xml. Then I discovered that we had pretty much invented a poor implementation of eclipse, for the browser. In many ways I think a product such as eclipse is a much better substitute for a browser when it comes to distributing applications, having many of the benefits of JNLP (the ability to update from within the environment via the web), it is truly a joy to program with and the ease with which it can be extended via plugins is nothing short of phenomenal.
Many user interface issues associated with Java are minimized by the use of SWT (performance and look and feel).
Availability on nearly all major platforms makes it more attractive than Windows only alternatives.
After the initial install there is no delay in startup typical of applets, and certainly no concern with browser compatibility.
The environment promotes good programming practices (separtion of business logic and UI code for example).
IMHO it''s worth checking out if you have an application that has to maintain complex state and provide a rich set of UI widgets. Otherwise stick to DHTML.
Regards,
Charlie
#22
Peter Ent commented on 8 Nov 2003
A quick retort to Mr. Prescott''s comments about Flash:
a) Flash does not have a single-threaded approach?? What?? On the contrary, you can have many requests going out and responses coming back simultaneously AND have a responsive GUI! Very difficult to get this right in Java without a lot of code.
b) Flash has Excellent separate between client-side state handling and the UI. That''s what Flash is all about. The MVC architecture is easy to do in Flash!
c) I think open-source to Flash is more difficult because it is more complex. Macromedia has gone a long way in MX 2004 with its Halo UI Elements for both Flash and HTML. Plus you can now use CSS in both Flash and HTML to give your web app a seamless look.
I would encourage you, Mr Prescott, to download a trial version of Flash or to at least look at their demos.
#21
Mack commented on 7 Nov 2003
Windows Client? Not everyone is using Windows if you didn''t notice.
Anyway, is this something new?? Comeon, we''ve been deploying applets for ages, and now use JNLP/Webstart.
#20
Ed commented on 7 Nov 2003
Why not just use an MS Windows client ..... MS Windows is the standard interface in business .... there are many languages to choose from, most of which are significantly faster and more suited to client development than Java .... I know this is a Java forum but it''s important to follow the best practice for the business, not to select an approach based on developer biases .... just my 2 cents .....
@@ Ed @@
#19
Nathan Christiansen commented on 7 Nov 2003
I have been developing Java Webapps for over 7 years and DHTML webapps for over 6 years. I have found that a combination of these two technologies are a very good combination.
I have some issues with the article.
From the Article: "...not validating the input from every field.... While it is possible to work around some of these problems using very sophisticated DHTML scripts, doing so requires stretching the capabilities of DHTML beyond the limit that can be easily maintained."
I really don''t see how it is more complicated and less easy to maintain than single field validation in Java. In both languages you need to attach a method/function to an event on each of the form''s fields (onchange="" in DHTML). In fact there is less coding in DHTML to make this attachment. And in both you have to maintain separate code for the validation, you can even correct formats in both. It seems tom me that the author is speaking from inexperience in ECMA Script.
From the Article: "...supporting better user interface controls such as tables that keep their column or row headers fixed when the data is scrolled...". It is obvious that the author is unfamiliar with the W3C Web Accessibility Initiative (WAI), where this is an accessibility requirement for browsers. (See the "navigating THEAD, TBODY, TFOOT with CSS overflow styling" test case (However, IE fails this test case): http://www.w3.org/WAI/UA/TS/html401/cp1001/1001-THEAD-TBODY-TFOOT-OVERFL...)
I do agree with the Author that "''tree controls'' that allow the user to display data in a collapsible hierarchy" are more difficult to write using DHTML complying to web standards, but it can be done (as I have done it myself).
More power in the ability to program your GUI does not mean a better user experience. Nor does GUI interactivity. It is the measure of usability that means a better user experience.
I agree with those who say that applets aren''t much use for anything, for all of the reasons given by the other posters.
I really expected this article to be about JNLP and Java Web Start. Now *that* is a good way to bring Java to the client. Add in great open source libraries like JFreeReport and JFreeChart, Prevayler, etc. and you can develop some really awesome client-server applications that install themselves on the user''s desktop, keep themselves up to date automatically, and look very much like a native application. This makes Java the logical successor to PowerBuilder, SQL Windows, VB, etc.
I use Java client apps every day, on both Windows and Linux, and have written several.
#17
Michael Prescott commented on 7 Nov 2003
Flash is an interesting alternative, but it has a lot of shortcomings from a business software perspective as a result of its multimedia origins. Binary source, its single-threaded call-back approach to server calls, and a lack of good separation between client-side state handling and UI. General Interface looks very interesting, although it''s hard to believe that open source hasn''t delivered a project based along these lines.
Tim wrote: "Developing full-featured Applets for Java, can be quite difficult. However, seeing an Applet which is indistinguishable from a local application, running full-size, inside a browser, is an amazing thing!"
While looking for car parts, I stumbled into one of those:
http://www.rockauto.com/ has a online part catalog front-ended by an applet that blended very well with surrounding HTML.
With more OEMs putting Sun JREs on new computers and broadband connections that make downloading Sun JREs and larger applets, I wouldn''t count Java out quite yet on the client. However, It needs the "killer-app" that will motivate Joe and Jane Internetuser to download Sun JREs
Matt wrote: Excellent article! I have been developing Swing clients for over two years for a large scale business application. We switched from Microsoft 2-tier to N-tier using J2EE. We decided upon Swing clients for several reasons. 1) We wanted to have a consistent language on the client in the middle tier 2) We wanted the same look and feel as our existing applications. Users and our application designers are familiar with the MDI application. We did not want to reinvent existing standards. 3) JNLP(Web Start) were new but would provide the answer to reducing deployment costs. 4) A quick response for data entry was a requirement. 5) The complexity of the UI could only be done in Swing.
This project has approx. 70 developers and 50 client apps. Some VB applications still exist but once the migration is complete we will have a browser based portal which will be the center of the users job...
John Johanson wrote: Java, Swing, and JNLP (Java Web Start) is the future. F.E. ScheduleWorld is a pure Java/Swing/JNLP Outlook replacment that is interoperable with Outlook/Exchange/Notes/etc.. over email. It''s secure, fast, free, and the server service and interoperability bridge is free as well. It''s an excellent example of why Java is the best way to go and proof that truly great applications simply can not be written with a web front-end.
Chris Murphy wrote: With more than 50% of computer manufacturers intending to put a JRE on their new machines in the future the biggest problem will come to be moving Data Objects across firewalls with some sort of a transaction layer. The objects won''t need to be distributed, but appear to be so within the context of the transaction. I think the terminology here is ''course grained''. I think that SDO (Service Data Objects) will make a contribution in this area. With SDO/JDO, will we finally be able to code to update data objects over the net as if we were writing a client/server application to a local OODB?
Mohee Jarada wrote: I agree with the author article regarding that either Java clients (SWING apps) or Java Applets can be a replacement for DHTML Web technology when internet network bandwidth is faster.
The only thing he forgot to mentioned talking about the Java Clients network communication problems like serlization and de-serialization problems of heavy java objects travelled from Java Clients to Web Java servers.
Also Microsoft had made a big mistake when they re-shaped the web technologies just for their interests and they collapesd the meaning of a platform independent concept, and just year by year creating a headache technology instead of smooth, simple and stable platform!!!!
Brooks wrote: Agreed it''s odd author didn''t mention Webstart. I''ve developed in VB desktop, asp, ColdFusion and jsp/servlets. My VB desktop applications provided extremely rapid and bullet proof data entry that only something like Flash could begin to equal in a web based app ( but I''ve had probs getting Flash apps to download and work properly) The growing power of desktops further argues for desktop apps. That said, I agree with writer who said Java was cumbersome and much faster to use, e.g., Python. Given that VB.NET and C# are much more like java than Python, I see no real advantage to going there (and also eliminating all Linux machines for your app). So, give us the concept of Webstart (with smart updates of just the parts that changed) in a language like Python with, e.g., type-ahead combo boxes and life would be lovely and my users much happier.
John wrote: Developing full-featured Applets for Java, can be quite difficult. However, seeing an Applet which is indistinguishable from a local application, running full-size, inside a browser, is an amazing thing! Unfortunately I''ve seen too many developers give up out of frustration, just before making the critical breakthrough.
To help more people realize this epiphany, I have created a small, completely free framework, hosted at the java.net website. It''s both simple and very powerful. Amongst other things, it shows how to create Applets which have all the features of a Java application, with no need to sign the codebase! (Naturally it won''t let you write to the client''s hard drive)
If you are ready to get really excited about Java again, visit:
https://cajo.dev.java.net
Note: some developers have called the project ''rocket-science'' to understand, but all have agreed it is ex...
Charlie Fulnecky wrote: Having just come off of a major project using DHTML on the client I can attest to the power ... dynamic trees, tables, context menus, etc. and also the pain. The development environments are far less mature compared with those available for Java(currently using JDeveloper and Eclipse) and the poor implementation of standards makes X-browser support a nightmare. My team spent 6 months creating a web-app that used xml and xmlhttprequest objects to maintain state on the client, we built a robust framework of widgets that included movable windows, dynamic trees and tables and full featured menus/context menus built on xml. Then I discovered that we had pretty much invented a poor implementation of eclipse, for the browser. In many ways I think a product such as eclipse is a much better substitute for a browser when it comes to distributing applications, having many of the benefits of JNL...
Peter Ent wrote: A quick retort to Mr. Prescott''s comments about Flash:
a) Flash does not have a single-threaded approach?? What?? On the contrary, you can have many requests going out and responses coming back simultaneously AND have a responsive GUI! Very difficult to get this right in Java without a lot of code.
b) Flash has Excellent separate between client-side state handling and the UI. That''s what Flash is all about. The MVC architecture is easy to do in Flash!
c) I think open-source to Flash is more difficult because it is more complex. Macromedia has gone a long way in MX 2004 with its Halo UI Elements for both Flash and HTML. Plus you can now use CSS in both Flash and HTML to give your web app a seamless look.
I would encourage you, Mr Prescott, to download a trial version of Flash or to at least look at their demos.
Mack wrote: Windows Client? Not everyone is using Windows if you didn''t notice.
Anyway, is this something new?? Comeon, we''ve been deploying applets for ages, and now use JNLP/Webstart.
Ed wrote: Why not just use an MS Windows client ..... MS Windows is the standard interface in business .... there are many languages to choose from, most of which are significantly faster and more suited to client development than Java .... I know this is a Java forum but it''s important to follow the best practice for the business, not to select an approach based on developer biases .... just my 2 cents .....
@@ Ed @@
Nathan Christiansen wrote: I have been developing Java Webapps for over 7 years and DHTML webapps for over 6 years. I have found that a combination of these two technologies are a very good combination.
I have some issues with the article.
From the Article: "...not validating the input from every field.... While it is possible to work around some of these problems using very sophisticated DHTML scripts, doing so requires stretching the capabilities of DHTML beyond the limit that can be easily maintained."
I really don''t see how it is more complicated and less easy to maintain than single field validation in Java. In both languages you need to attach a method/function to an event on each of the form''s fields (onchange="" in DHTML). In fact there is less coding in DHTML to make this attachment. And in both you have to maintain separate code for the validation, you can even correct formats in both. It seem...
J. Simmons wrote: I agree with those who say that applets aren''t much use for anything, for all of the reasons given by the other posters.
I really expected this article to be about JNLP and Java Web Start. Now *that* is a good way to bring Java to the client. Add in great open source libraries like JFreeReport and JFreeChart, Prevayler, etc. and you can develop some really awesome client-server applications that install themselves on the user''s desktop, keep themselves up to date automatically, and look very much like a native application. This makes Java the logical successor to PowerBuilder, SQL Windows, VB, etc.
I use Java client apps every day, on both Windows and Linux, and have written several.
Michael Prescott wrote: Flash is an interesting alternative, but it has a lot of shortcomings from a business software perspective as a result of its multimedia origins. Binary source, its single-threaded call-back approach to server calls, and a lack of good separation between client-side state handling and UI. General Interface looks very interesting, although it''s hard to believe that open source hasn''t delivered a project based along these lines.
Peter Ent wrote: Interesting... what about Macromedia Flash? It''s on nearly every computer, is cross-platform (really, write once, run everyone), cross browser, and, in MX 2004, has more UI controls than Swing. Plus a smaller download. I''ve been developing Java/Swing applications for years, but Flash just blows it away.
Mr Evident wrote: It is incredible: a lot of grown ups, with computer science degrees and a lot of years of experience have not yet realized that Java, while interesting and very "cool" is COMPLETELY INAPPROIATE for almost any type of real life solution. 99% of the current projects being done with Java would be better done (and in 1/10 of the time) with Perl, Python, PHP, etc.
Matt Heckel wrote: Jonathan Pierce.... give us a break. "The upcoming Click-Once" technology heavily embedded in the ''new'' Longhorn (2005) OS"??? First, Java''s WebStart coined the phrase ''One-Click Deployment'' at least 3 years ago. Secondly, no wonder M$ is fighting tooth and nail to keep the JRE out of their OS. They have new big plans to capitalize on others innovation. If they didn''t keep it out, no one would give a rat''s a$$ about Longhorn.. unless of course it didn''t need constant updating with service packs and reboots to keep it alive. Oh yeah, that''s their idea of innovation.
Denis Robert wrote: "ClickOnce" is not the solution, unless it''s for an intranet in an All-M$ shop. These are the same shops for which .NET makes any sense whatsoever. Nor is it anything new; Others before have rightly pointed to JNLP, which offers automated deployment of rich clients, as a solid solution.
Nor is Flash the solution for anything but the most trivial apps. Flash apps become quickly unmanageable, with code all over the place. MX has helped, but it''s still a nightmare. And XML support is still weak (at best).
At this point in time, the only two real options for HTTP-based delivery of client apps are DHTML and Java (whether JNLP or Applets). In an intranet setting, where deploying a real JVM is not a major issue, Java makes more sense; for internet apps, DHTML is still (unfortunately) the only workable option. One can use Flash for the odd small component, but for anything with any meat,...
Swisscom, the Swiss telecom, is going into the cloud business.
Its subsidiary Swisscom IT Services AG has signed up with Red Hat as a Certified Cloud Provider and launched a public cloud Infrastructure-as-a-Service (IaaS) cloud targeting enterprise-class customers primarily in ...
Apache Deltacloud, the Red Hat-contributed ReSTful API that abstracts differences between clouds so services on any cloud can be managed – provided of course there’s a driver – has graduated from the Apache Foundation’s incubator and is now a full-fledged Top-Level Project (TLP)....
In a surprise move on Tuesday, January 10, Oracle wheeled out its Big Data Appliance.
That’s the one it said in October would be ready sometime in the first half. Only nobody believed it meant early in the first half. Heck, it’s not even clear anybody thought Oracle could make ...
Rackspace Hosting, the service leader in cloud computing, on Thursday announced its acquisition of SharePoint911, an industry leader in SharePoint consulting, training, and "JumpStart" services within SharePoint. The unification of both companies provides capabilities to deliver ...
CloudLinux, Inc., on Thursday released CafeFS 3, a virtualized file system for shared hosters that cages each customer within its own virtualized file system.
CageFS becomes part of CloudLinux OS at no additional charge. CloudLinux OS, the only commercially-supported Linux OS m...
About Newsfeeds / Video Feeds
.gif)
Swisscom, the Swiss telecom, is going into the cloud business.
Its subsidiary Swisscom IT Services AG has signed up with Red Hat as a Certified Cloud Provider and launched a public cloud Infrastructure-as-a-Service (IaaS) cloud targeting enterprise-class customers primarily in ...
Apache Deltacloud, the Red Hat-contributed ReSTful API that abstracts differences between clouds so services on any cloud can be managed – provided of course there’s a driver – has graduated from the Apache Foundation’s incubator and is now a full-fledged Top-Level Project (TLP)....
In a surprise move on Tuesday, January 10, Oracle wheeled out its Big Data Appliance.
That’s the one it said in October would be ready sometime in the first half. Only nobody believed it meant early in the first half. Heck, it’s not even clear anybody thought Oracle could make ...
Rackspace Hosting, the service leader in cloud computing, on Thursday announced its acquisition of SharePoint911, an industry leader in SharePoint consulting, training, and "JumpStart" services within SharePoint. The unification of both companies provides capabilities to deliver ...
CloudLinux, Inc., on Thursday released CafeFS 3, a virtualized file system for shared hosters that cages each customer within its own virtualized file system.
CageFS becomes part of CloudLinux OS at no additional charge. CloudLinux OS, the only commercially-supported Linux OS m...
