Discussion on:
View:
Show:
Current version of Lotus Notes and Lotus Symphony are based on Java + Eclipse/SWT. Future version of the programmers' IDE for Notes (Domino Designer) will also be based on this. As corporate users upgrade to the new version of Notes, and as they deploy the Symphony office suite for basic users, Java + Eclipse/SWT will be used by millions of corporate users world-wide, even if they don't know it.
Hi,
This is Richard Monson-Haefel of Curl Inc. We also offer a "presentation layer abstraction". In fact, Curl came out in 1998 so it predates Adobe flex and silverlight. We've been offering a platform that provides both RIA and desktop runtime since 2004.
I think you missed a few things in your analysis. First, when Java applets came into vogue (I was there writing them) consistency among implementations of the JVM was horrible across browsers. This is why its failed. The same was true of DHTML which is today called Ajax.
The pore portability story around Java was solved for the most part when Sun took charge and offered their own browser plug-ins, rather than trusting vendors to implement the JVM properly. Sadly (for Sun), however, Java already had a stink about that they just can't shake on the desktop.
Java was/is also a bit of pig in terms of performance on the desktop - that too has stymied its growth as "presentation abstraction"
The same cannot be said for Silverlight, Adobe Flex/AIR or Curl. These technology do not have a lingering stink about them - they are, from the perspective of developers, fresh. In addition, they also leverage existing developers skills in web presentation (Adobe) and .NET knowledge (Silverlight). Curl is the least familiar of the RIA platforms but its been in production use in Asia for five years, its much faster, and more secure. So Curl has its own strengths.
Anyway, you need to look at the whole picture. The truth is that in the future desktop abstractions will prevail. Of course, since my company offers such a thing I'm biased, but I'm also right.
All the best,
Richard
This is Richard Monson-Haefel of Curl Inc. We also offer a "presentation layer abstraction". In fact, Curl came out in 1998 so it predates Adobe flex and silverlight. We've been offering a platform that provides both RIA and desktop runtime since 2004.
I think you missed a few things in your analysis. First, when Java applets came into vogue (I was there writing them) consistency among implementations of the JVM was horrible across browsers. This is why its failed. The same was true of DHTML which is today called Ajax.
The pore portability story around Java was solved for the most part when Sun took charge and offered their own browser plug-ins, rather than trusting vendors to implement the JVM properly. Sadly (for Sun), however, Java already had a stink about that they just can't shake on the desktop.
Java was/is also a bit of pig in terms of performance on the desktop - that too has stymied its growth as "presentation abstraction"
The same cannot be said for Silverlight, Adobe Flex/AIR or Curl. These technology do not have a lingering stink about them - they are, from the perspective of developers, fresh. In addition, they also leverage existing developers skills in web presentation (Adobe) and .NET knowledge (Silverlight). Curl is the least familiar of the RIA platforms but its been in production use in Asia for five years, its much faster, and more secure. So Curl has its own strengths.
Anyway, you need to look at the whole picture. The truth is that in the future desktop abstractions will prevail. Of course, since my company offers such a thing I'm biased, but I'm also right.
All the best,
Richard
Richard -
Thanks for the response! Yes, I am passingly familiar with Curl, but I admit that I omitted mention of it from my post due to failure to remember about it.
You are right about the JVM consistency issue, and the performance issues (I was there too, it was not so great). And yes, Sun didn't get the issues sorted out until Java's repuation had been battered pretty badly.
But those issues have been straightened out for a number of years now, and Java enjoys a huge base of existing developers who know the language and APIs; they would just need to learn the appropriate presentation controls. But Java is still going nowhere as a presentation abstraction system.
Now, that being said, I'd love to learn more about Curl and what you guys are doing, and maybe discuss it either here or in another space that I am writing for!
J.Ja
Thanks for the response! Yes, I am passingly familiar with Curl, but I admit that I omitted mention of it from my post due to failure to remember about it.
You are right about the JVM consistency issue, and the performance issues (I was there too, it was not so great). And yes, Sun didn't get the issues sorted out until Java's repuation had been battered pretty badly.
But those issues have been straightened out for a number of years now, and Java enjoys a huge base of existing developers who know the language and APIs; they would just need to learn the appropriate presentation controls. But Java is still going nowhere as a presentation abstraction system.
Now, that being said, I'd love to learn more about Curl and what you guys are doing, and maybe discuss it either here or in another space that I am writing for!
J.Ja
Presentation abstraction layering will never happen until developers take on the idea of it being a layer.
To me one layer for presentation is exactly the wrong way to go to achieve the abstraction, especially if it's seriously entangled with a certain 'way' of doing things. It shouldn't matter to the functionality how it's presented is the real abstraction, not whether it gets hosted in IE, VMS or a 'nix shell.
The best model is the basic one in linux, not because it's not windows, but because designing for command line and gui and maybe web based means you gain from separation of concerns. Turning a non-trivial app that was designed for only one sort of interface into another is fraught with difficulty. Indeed it's why a lot of past attempts have been so f'ing awful.
As soon as you design an application from it's front end, you put all sorts of contraints on it, divorcing what it needs to do and what it needs to do it, from how you tell it to do those things is seriously difficult unless you make the choice right from the get go that you are going to tell it to do the 'same' things in several different ways.
To me one layer for presentation is exactly the wrong way to go to achieve the abstraction, especially if it's seriously entangled with a certain 'way' of doing things. It shouldn't matter to the functionality how it's presented is the real abstraction, not whether it gets hosted in IE, VMS or a 'nix shell.
The best model is the basic one in linux, not because it's not windows, but because designing for command line and gui and maybe web based means you gain from separation of concerns. Turning a non-trivial app that was designed for only one sort of interface into another is fraught with difficulty. Indeed it's why a lot of past attempts have been so f'ing awful.
As soon as you design an application from it's front end, you put all sorts of contraints on it, divorcing what it needs to do and what it needs to do it, from how you tell it to do those things is seriously difficult unless you make the choice right from the get go that you are going to tell it to do the 'same' things in several different ways.
Yup, too many developers are *still* not thinking in terms of layer separation. Heck, it doesn't even need to be three tiered (or N-tiered), just, "stop putting the text to output in the statement itself!" and "put the DB work in a separate library!" But too many people have too few reasons to do this, plus time constraints, plus the, "but the manager swore this would never need to change, so why should I separate it!" routine, so of course it never happens.
J.Ja
J.Ja
Most applications on the linux platform are written for the command line interface. With the output for user interaction just being sent to stdout.
This means that the application can easily be given a GUI front end any time, which is what created most GUI based applications for linux. OR, you can put it into the cgi area and use it as a web app with just a wrapper to add the headers and links needed.
While the Common Gateway Interface is currently out of vogue for perceived security risks, it is still one of the better ways to gain a stateful connection within the http environment, without the additional security risks of active clientside scripting.
Thinking about the idea of the blog entry, I will hazard a prediction, that we will see significant improvements in web app design for the thin client model that is behind the entry from the open source community long before we see such from any proprietary software house. It is an easier step from any of the open source operating systems with their excellent cli environments to move into the thin client distributed applications market than from the commercial / proprietary systems obese client environment.
[ caveat: though getting the open source community to see the need is required before this will happen ]
This means that the application can easily be given a GUI front end any time, which is what created most GUI based applications for linux. OR, you can put it into the cgi area and use it as a web app with just a wrapper to add the headers and links needed.
While the Common Gateway Interface is currently out of vogue for perceived security risks, it is still one of the better ways to gain a stateful connection within the http environment, without the additional security risks of active clientside scripting.
Thinking about the idea of the blog entry, I will hazard a prediction, that we will see significant improvements in web app design for the thin client model that is behind the entry from the open source community long before we see such from any proprietary software house. It is an easier step from any of the open source operating systems with their excellent cli environments to move into the thin client distributed applications market than from the commercial / proprietary systems obese client environment.
[ caveat: though getting the open source community to see the need is required before this will happen ]
The *Nix model does make sense, and it does lend itself well to modularization. The biggest problem is that historically, the decisions behind the format of that input/output have stunk. Someone will write "garbage app 0.01a" and release it as open source. ga0.01a will be filled with dumb quirks, since it was a personal use app that happened to be open sourced. Six seconds later, 5 other developers start building off of ga0.01a since it fills a need they have. Now, ga0.01a's I/O patterns just became the de facto standard for data interchange for that purpose. The author of ga0.01a is working on ga0.02f, and wants to fix the quirks, but they can't, because all of these other tools are depending on the quirks. So instead, the default behavior is still "quirk mode" with a command line flag for "new I/O", which no one uses since it is not the default and everything relies upon "quirk mode" anyways. By the time ga0.03j is being developed, Richard Stallman is releasing "gga" (GNU Garbage Application), djb has come out with french-kiss, which has all of ga's functionality, but works totally differently, but installs a link to itself in /usr/local/bin (ga's default install location) named "ga" which really calls "french-kiss" with a flag to turn on "ga compatability mode", and some kid has made $10 million selling a 2 month old startup to Google that does nothing more than run some standard database data through ga and then map the result with Google Maps on the IntarWeb. Meanwhile, ga's rediculous quirks will live on for another 30 years, despite having been corrected within 2 months by the application author.*
Bleh.
Yes, the *Nix modularization is good in a great many ways, but that good comes at a price, which is that the barrier to entry for really bad decisions is very, very low.
J.Ja
* See also: sendmail
Bleh.
Yes, the *Nix modularization is good in a great many ways, but that good comes at a price, which is that the barrier to entry for really bad decisions is very, very low.
J.Ja
* See also: sendmail
You have to think forward, that of course can be difficult. 
Locking yourself in a particular path too early is a mistake so common, I'm almost immune to it.
The one that makes me howl still, is nix developers ongoing love affair with terseness.
I know they were all two fingered typists, but please 26 one letter parameters only four of which any person new to the interface could guess at by context...
Course you can always fall back on ? h -h --h --help .......
There again that's not the mechanism but the content, you can always configure it out by piping in your own command pre-processor.
Locking yourself in a particular path too early is a mistake so common, I'm almost immune to it.
The one that makes me howl still, is nix developers ongoing love affair with terseness.
I know they were all two fingered typists, but please 26 one letter parameters only four of which any person new to the interface could guess at by context...
Course you can always fall back on ? h -h --h --help .......
There again that's not the mechanism but the content, you can always configure it out by piping in your own command pre-processor.
said every app was useful, only that the developers for the open source operating systems have the mindset that will enable them to implement a good system, if they perceive the need.
it's the anti-bloat stance most take that will help, rather than the bloated app stand of most proprietary development houses.
it's the anti-bloat stance most take that will help, rather than the bloated app stand of most proprietary development houses.
i can write a book about the subject, so i'll get to the point:
the success and widespread of a platform (silverlight, flash etc...) is a direct result of a major success in terms of $$$.
Web applications rose beacuse of individulas like Amazon.com who made ridiculous amount of money, thus, creating a massive wave of followers (followers that wanted to capitalize the same way).
it is the same as Reality TV: it existed for ever as game shows and others but it took "Survivor" to create a mass widespread of the format.
IN the END Technolgy becomes widespread if you have a croud of followers (follwing a massive success).
SO, if i were Microsoft (or Adobe..) i would have to create a cross platform enterprise who created ridiculous amount of money (in a Dummy Sub Start-up)!!!
you can't just wait for it to happen on it's own...
the success and widespread of a platform (silverlight, flash etc...) is a direct result of a major success in terms of $$$.
Web applications rose beacuse of individulas like Amazon.com who made ridiculous amount of money, thus, creating a massive wave of followers (followers that wanted to capitalize the same way).
it is the same as Reality TV: it existed for ever as game shows and others but it took "Survivor" to create a mass widespread of the format.
IN the END Technolgy becomes widespread if you have a croud of followers (follwing a massive success).
SO, if i were Microsoft (or Adobe..) i would have to create a cross platform enterprise who created ridiculous amount of money (in a Dummy Sub Start-up)!!!
you can't just wait for it to happen on it's own...
You make a great point there. No one is showing that these systems can be provably (or even aguably)better than Web apps, let alone show that there is a business model to follow or that money can be made. Until that happens, they will be perceived as a big risk.
J.Ja
J.Ja
You say "Java + Swing/AWT, Silverlight, or AIR...none of them seem to be big-time successes..." But in the case of the latter two, it is much too soon to make a determination of success.
You are right that it is too soon to say for sure about Silverlight or AIR. But I hear a lot of people saying, "I'll give 'em a try when I get some time", which is a far cry from, "the boss is sending me to training next week on this, since we're starting a project with it in a month." So yeah, while the metric of "traction" is definitely different, I am still seeing little evidence of it.
J.Ja
J.Ja
Yes there are quite a few things to consider.
The Fastest, Easiest way to learn DotNetNuke! Free Trial Lessons!! http://www.applydnn.com
The Fastest, Easiest way to learn DotNetNuke! Free Trial Lessons!! http://www.applydnn.com
OK, now Java might have solved some of it's performance problems and is as slow/fast as silverlight.
OK, also plenty of programmers know the language and the API.
But why it failed is clear: A web app (rich or not) is supposed to be sexy. And you can do this perfectly with flash and silverlight, while any java app looks definitely 80'ies style.
Just my two bits though!
Markus
OK, also plenty of programmers know the language and the API.
But why it failed is clear: A web app (rich or not) is supposed to be sexy. And you can do this perfectly with flash and silverlight, while any java app looks definitely 80'ies style.
Just my two bits though!
Markus
We develop business applications with a very long deployment life. So for us an abstraction layer both from the presentation technology (Desktop, Web, text, ...) as also from the OS.
Actually the big ERP vendors showed, that this is possible. Products like SAP and BAAN showed, that with the right architecture you can develop a SW (actually in the 80'ies), make it run initially in ascii based interface, and migrate it with ease to windows and web based platforms.
So if the holy grail is clear and if companies proofed, it can be done, where are the developer tools for small companies to repeat the miracle?
In other words: Which abstraction layers do you know/recommend for Presentation, Database etc.
Eager top hear your ideas,
Markus
Actually the big ERP vendors showed, that this is possible. Products like SAP and BAAN showed, that with the right architecture you can develop a SW (actually in the 80'ies), make it run initially in ascii based interface, and migrate it with ease to windows and web based platforms.
So if the holy grail is clear and if companies proofed, it can be done, where are the developer tools for small companies to repeat the miracle?
In other words: Which abstraction layers do you know/recommend for Presentation, Database etc.
Eager top hear your ideas,
Markus
Markus -
My apologoes for the late response. I really don't have a particular recommendation at the moment. A lot of it has to do with your needs and circumstances. If you are doing something where you can guarantee that everyone is using Windows, Silverlight looks decent at the moment, but I haven't worked it it personally. I think Flash is a surprisingly good choice, particularly with the platform independence, and the vector graphics take up little bandwidth to transmit. I think that HTML is not a good choice most of the time, mainly because of the HTTP protocol, but it is often the only choice.
J.Ja
My apologoes for the late response. I really don't have a particular recommendation at the moment. A lot of it has to do with your needs and circumstances. If you are doing something where you can guarantee that everyone is using Windows, Silverlight looks decent at the moment, but I haven't worked it it personally. I think Flash is a surprisingly good choice, particularly with the platform independence, and the vector graphics take up little bandwidth to transmit. I think that HTML is not a good choice most of the time, mainly because of the HTTP protocol, but it is often the only choice.
J.Ja
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
