Using a web browser for interactive applications is kind of like using email as an interface for a spreadsheet. I had thought that batch systems went out of fashion in the 1970s...
Fundamentally, the reason HTML is popular is because so far it has come the closest to the "sweet spot" between large components on the one hand (say, ActiveX, Java applets, etc which have lots of functionality, but are too specific to be reused between applications), and fine, finicky detail on the other (such as X windows, or Windows remote desktop, where each and every pixel is drawn).
Before GUIs, the standard was telnet, which was almost ideal. It was simple, yet expressive. It broke the user interface down into a small number of items (characters, some control codes for positioning, colours, etc.) and a limited event model (every keystroke was an event that was sent - the application determined how that would be reflected on the display). To make programming easier, there were a number of libraries and toolkits (curses, Jam, various menu builders), but those all ran on the server side - the client had a single, simple, consistant interface that could be relied on (mostly - there was no error correcting protocol, so often a screen could get jumbled on a noisy line, so programs often had "refresh" commands).
There needs to be an equivalent that uses GUI components - buttons, text panels, tabs, layout panels, and so on. The list of standard controls is now well known - a useful set is defined in XUL or Microsoft's XAML. All that is really needed, I think, is a useful protocol for sending them to a GUI equivalent of telnet, and a simple way of getting events back - and a sample implementation. Sending an entire user interface document across isn't flexible enough, an application needs to be able to add, remove, enable/disable elements, or otherwise update the display piece by piece, just like telnet could.
A protocol was submitted to the WWW3 consortium, it's called XUP for eXtensible User-interface Protocol. It uses SOAP over HTTP to construct a user interface, and receive events for the application to process. The user interface language is unspecified, it could be XUL or XAML or something else.
I think that's a step in the right direction, though it would be better with a sample implementation. I think it also has too many layers to make it something that would be popular, and using HTTP goes through too many slow connect/disconnect cycles. I've been working in my spare time (very little, no working code yet) on a similar idea with fewer layers - basically just text messages over a persistant two say serial connection, which I've called HICP, or Holistic Interface Control Protocol. It's just past the "wishful thinking" stage, but I do think it has potential.
Ideally, something like this would be a browser plug-in or extension, so it would be widely available. Then when you connect to a rich application URL, you immediately get a window and full user interface, independent of language - your server could be Java, Python, .NET, or a combination, while your client might be implemented as a Java applet, or a GTK+ Mozilla extension, or IE plug-in.
> I think that's a step in the right direction, though it > would be better with a sample implementation. I think it > also has too many layers to make it something that would > be popular, and using HTTP goes through too many slow > connect/disconnect cycles. I've been working in my spare > time (very little, no working code yet) on a similar idea > with fewer layers - basically just text messages over a > persistant two say serial connection, which I've called > HICP, or Holistic Interface Control Protocol. It's just > past the "wishful thinking" stage, but I do think it has > potential.
This sounds like a good idea. However (if I interpret the XUP idea right) you will not have any intelligence on the client side. Simply every event is wrapped in a SOAP message and sent over HTTP.
I agree with you that SOAP and HTTP is way too slow for this. But even if you replace SOAP and HTTP with your own protocol (I guess you will need to keep a connection open, what could be a problem in most corporate network environments) you need to consider the granulartity of events. In a GUI application running locally you will have events such as mouse position available. This would be an overkill as every mouse movement would have be transmitted and processed by your server. So you will end up with a subset of events. This is at the end not so different to the situation we have at the moment with html (and improvements of modern frameworks like ASP.NET). You will have further restrictions for security reasons.
I think you will not get around allowing the client to have some intelligence. This however leads you to an applet style framework (that has failed) or an rich client approach.
> I agree with you that SOAP and HTTP is way too slow for > this. But even if you replace SOAP and HTTP with your own > protocol (I guess you will need to keep a connection open, > what could be a problem in most corporate network > environments) you need to consider the granulartity of > events. In a GUI application running locally you will have > events such as mouse position available. This would be an > overkill as every mouse movement would have be transmitted > and processed by your server. So you will end up with a > subset of events. This is at the end not so different to > the situation we have at the moment with html (and > improvements of modern frameworks like ASP.NET). You will > have further restrictions for security reasons.
This is, in a sense, reinventing X-windows. We already have VNC as a mechanism for optimizing remote access to multiple 'desktop' types. But, there is not opportunity for local interworking as well as some more barriers to productivity.
> I think you will not get around allowing the client to > have some intelligence. This however leads you to an > applet style framework (that has failed) or an rich client > approach.
Applets failed because Microsoft made sure there was not a single platform standard, and because of bugs that opened users to remote exploits. So, in a sense, it was too early to market before being proven.
We used applets for a fairly large application for some time. But, users, ultimately decided that the browser was too burdensome. If they clicked on a link in an email, or typed a URL into their address field on the taskbar, and they did not have 'open new windows' set in the browser, the applet would get closed and that pane reused for the new URL.
There are just a large number of issues here. The JavaWebStart mechanism starts to fix these issues because it launches a new process independent of the browser, but is till launchable from a web page. Anyone who hasn't tried JavaWebStart could try out James Goslings Juicy News Network RSS client out on http://jnn.dev.java.net. That will show you how JavaWebStart works currently.
There are some issues with JavaWebStart not providing enough flexibility in JVM startup, but these issues can be worked.
We have been using WebStart for deployment of our app over the Web, and it works really well. We're finding that browsers are becoming a less useful mechanism for delivering mission-critical apps, because of viruses, spyware, and the consquent draconian security measures implemented in some browsers.
I also think that Applets might have a comeback, since the applet and Webstart mechanisms are now merged with JDK1.5. For instance, the same caching mechanisms are used for both. That can speed up applet startup.
Many users, though, still prefer a dedicated icon on their desktop for frequently used apps.
I also see a huge growth in rich-client apps coming over the next 1-2 years. Observe the many "rich-client" platforms emerging. E.g., Spring, Eclipse, etc. And IBM is basing their entire line of sofware for small businesses on an Eclipse UI delivered via the Web.
> I also see a huge growth in rich-client apps coming over > the next 1-2 years. Observe the many "rich-client" > platforms emerging. E.g., Spring, Eclipse, etc. And IBM is > basing their entire line of sofware for small businesses > on an Eclipse UI delivered via the Web.
Frank I agree with this. Having worked mainly in the .NET area in the last two years I have to say though that the Java community has to catch up on some issues: The many (very good) Java IDE's lack GUI designers that match Visual Studio's functionality. The second area where I see .NET providing much better support is when it comes to debugging (in particular web services).
I really see the platform that provides superior development tools to win the "rich-client-war".
"Applets failed because Microsoft made sure there was not a single platform standard"
No, applets failed for performance reasons. They take too long to load and are pokey.
The same dynamic widgets can be faked in dhtml/javascript with much better performance than you can get with java/awt/swing. This is why maps.google.com is dhtml and not an applet.
> "Applets failed because Microsoft made sure there was not > a single platform standard" > > No, applets failed for performance reasons. They take too > long to load and are pokey.
This is a little risky to state unequivacally. I've seen plenty of well written applets that work just fine. Applets were simple enough to start that poor applets were easy to create without having to learn much about the programming environment. The event model changes made many applets that I saw behave poorly. There are some many issues with why applets could have poor performance. But, the platform overall is not the big issue.
> The same dynamic widgets can be faked in dhtml/javascript > with much better performance than you can get with > java/awt/swing. This is why maps.google.com is dhtml and > not an applet.
There is quite a bit that you can do with dhtml and javascript that can also be done with java. The only advantage is that the dhtml/javascript, in general, comes with the html document so that the HTTP connection overhead for another connection is avoided.
In general, there are some really good gaming applets on production gaming websites which are applets. The issue is whether you need to use an applet or not. Proper design practices say that you wouldn't use an applet for something that the user would look at for 10 second. But, you could use an applet for something that the user would look at for 10 minutes, because the download delay would be less of an issue.
But, in the end, the real issue is the number of HTTP connections needed. The connection reuse changes in later version of HTTP help this issue.
The failiure of applets has up to know been blamed on:
- java performance - download delay - poor programming skills - number of connections needed - a microsoft conspiracy
really we just agree that they failed...
The google maps example is really nice, but quite simple too. It really is a clever written vector graphics viewer.
As I mentioned before in 1997 I beleived that soon all desktop applications will be replaced by some sort of browser hosted applications. It never happend. No one replaced Word, Excel, Photoshop or Powerpoint. The only application that I ever replaced with a web based application is my mail client. Hotmail is the only application that has ever replaced a desktop application on my computer.
Having developed a number of rich-client apps, I also have to say that there are design challenges not present in HTML-based apps, and therefore not as well understood or appreciated.
One of them is the caching data. Many rich-client apps gain their possible performance improvements from the ability to more intelligently transmit data, i.e., they can use the local machine's memory to cache data to reduce communication latency. For instance, Swing's MVC is designed for that kind of thing in mind.
For Web apps, there are well-known caching mechanisms, but not for rich clients. For a Web browser, caching is almost always a non-issue (which is part of the performance disadvantage). Caching in browser-based apps often takes place on the business tier or the Web tier. But for rich-client apps, there is often a cache on the client-tier which is physically distributed. In effect, rich-client apps often end up following a distributed 3-tier pattern, where you have the database, then you have a controller tier (often on a centralized server), and then you have a client tier, which is distributed.
So one issue then is how you're going to synchronize all those distributed clients. For instance, you may have a Swing table model that holds data objects representing, say, inventory items. As users add an inventory item, all the running table model instance need to updated, otherwise those client instances will become out of sync. With a Web app, the user typically reloads the page, which solves this problem. I suspect most rich-client apps don't pay too much attention to this as well, because it's a hard problem. But those apps then don't quite exploit all that's possible with the client toolkits.
I'd be interested to find more info on app patterns specific to rich clients. Does anyone know of some resources?
> I'd be interested to find more info on app patterns > specific to rich clients. Does anyone know of some > resources?
I would say what you are looking for is the observer pattern. Part of the MVC paradigm (btw invented at Parc Xerox beginning of the 1980s). As soon as the (data) model is changed by the controller it has to notify the view. However here lies the problem if you have a web or rich client application that is connected to a server through http. In this case your server should be able to send a message back to your client what is not really possible. Unless you can do that you never have a "real" MVC implementation. And I guess that's what you are after. Relying on a reload of a web page of course is not really solving problems either.
> > I would say what you are looking for is the observer > pattern. Part of the MVC paradigm (btw invented at Parc > Xerox beginning of the 1980s). As soon as the (data) model > is changed by the controller it has to notify the view. > However here lies the problem if you have a web or rich > client application that is connected to a server through > http. In this case your server should be able to send a > message back to your client what is not really possible. > Unless you can do that you never have a "real" MVC > implementation. And I guess that's what you are after. > Relying on a reload of a web page of course is not really > solving problems either.
Yes, it's the observer pattern. We actually tried to use the Jini remote event features, which are really a solution to this kind of a problem.
As you pointed out, firewalls are a problem when the server needs to call back to the client, unless we tunnel the communication through port 80. Even then, many firewalls sense that it's not HTTP traffic that's going through the port, and prevent that callback from occuring. In that case, one can still do an asynchronous refresh from client in a background thread.
Another problem is scalability, since the server would have to notify each client of updates, and there can potentially be a lot of clients. What I ended up doing was to create an RMI remote object instance for each customer. Each instance roughly corresponds to the set of clients that really care about data updates, so it's feasible to notify all of them (firewall issues permitting). In a previous rich-client project, we used IP multicast to notify client instances on the same network of updates. It was simple enough, but now I'd definitely use RMI remote events for that purpose (it was before Jini and RMI remote events).
Speaking of communication patterns, RMI seems to be tailor-made for rich-client Java apps on the Web, since both the client and server-side are Java. I don't see why use HTTP, etc., except for firewall issues perhaps. But even an applet can open an outbound socket to the server it came from (and to other servers as well, if the applet is signed). So outbound RMI calls are not really a problem.
Why is RMI not used more often on the Web? It does boost productivity tremendously, since we no longer have to worry about protocols, etc., just simply make method calls on objects.
Sure - but I'd ask your lead developer why he wouldn't use an applet for feature X and the answer he'll give you is pretty likely to be why they failed.
> The google maps example is really nice, but quite simple > too. It really is a clever written vector graphics > viewer.
Practically everything with a UI is.
> No one > replaced Word, Excel, Photoshop or Powerpoint.
PowerPoint - c'mon, go to any Sun presentation and you'll find them using web pages for slides (or openoffice on a Mac). No magic there.
Photoshop isn't there yet. Give it time.
If you pay attention to what is happening on Mac OS X with the new desktop widgets and Safari extensions to support them, you'll begin to see that browsers are getting more dynamic all the time. I think their API's suck donkey tails (javascript+html = ugly) but you certainly can get a lot done and the stuff scales DOWN (unlike Java applets which require a *lot* of boilerplate to get a simple form on the screen).
I'd say the emergence of dhtml/js rich interfaces is yet another nail in the strict-typing-lots-of-boilerplate-to-give-us-false-confidence coffin.
This works, that didn't. Or as we used to say in our youth - screw art, lets dance.
They are hardly replacements for excel and word. They are proofs that you can achieve an extremly simplistic application that _looks_ like excel or word. Exactly the same examples (just written as applets) let me beleive in 1997 that applets would soon take over the world! I mean, at least the applet examples had a potential to scale (as they were written in a decent language) but if you look at these examples I have a hard time to see how they even would evolve.
How did we get to the poor state of Web UI we're in today? There are many reasons. For example:
-Original Web specifications didn't address UI at all, just data transfer and semantic markup. -Early Web browser implementors attempted to quickly satify the huge demand for finer control of the UI, and built proprietary hacks to solve the problem. -The lack of a consistency among browsers has prevented many serious programmers from learning how to program the client, so most applications are just a shade better than connecting a dumb terminal to a server. No programmers meant no tools were developed, either. -Programmers, in general, have had a hard time adapting to the statelessness of HTTP. They try to mimic the behaviour of desktop applications instead.
Lately, we've seen Goolge and others demonstrate how much better the browsers have become in recent years. They now behave much more consistently. (We'll see if IE 7 will muck everyting up again.) It remains to be seen whether serious programmers can be attracted to client-side programming in any significant numbers. I also see very little market incentive for programmers to make this move: Most jobs are for server-side programming.
Flat View: This topic has 48 replies
on 4 pages
[
«
|
1234
|
»
]
Previous Topic
