System iNetwork

Thanks for starting this blog on an iseries rich client, Bill. I agree with your premise, and over time I hope to contribute more than opinions on it.

rd

I am in agreement also. I am new to Eclipse and I have yet to start developing an RCP.

After working in a shop that tried to provide all the desktop functionality in a browser, RCP is worth considering. I do suppose there will be some people who would bring up that AJAX has the potential to substantially improve the browser experience. I hope they will send in their thoughts also.

Forgive my ignorance, but do you have to install an RCP application on each PC? I have heard some systems administrators say that is why they like the browser based applications.

> but do you have to install an RCP application on each PC?

Yes, an Rich Client is an application like a word processor or Client Access.

Eclipse RCP has done a lot of work to make installing the Rich Client you create a painless process. An Ecllipse RCP application can be built that lives in one folder which carries everything it needs including the JVM (if you choose). This is very nice in situations where there is already another version on Java which may not be the one you want.

To install it just copy the generated install folder and make a shortcut to the launcher executable.

Some years ago I dove head first into desktop and client-server development using VB, Visual Foxpro, and Delphi. VB and Visual Foxpro compilers created small .exe files, but required runtime .dlls of 1.5 - 2.5 meg. Delphi created self contained .exe files that ranged in size from a about 3kb and up. My biggest application was about 4MB.

In client-server settings we normally used ODBC to access SQL databases, which might be deployed on remote servers. Performance of ODBC was constrained by network bandwidth. We adopted the term Fat-Client, which was unflattering, but appropriately fit the architecture. Most of the application logic was deployed to the desktop, which was a pain to manage and maintain.

If I understand correctly, the minimum RCP footprint is about 7MB, and deploying an application on top of that will perhaps double the footprint, and being written in Java, my guess is that the memory requirements would be about ten (10) times greater than the desktop applications I used to develop. If they were fat, wouldn't that make RCP obese?

Rich sounds more appealing, of course. But where did the term Rich-Client come from? And why was it adopted by the Eclipse community? The first time I heard it was in connection with AJAX technology, then later with Adobe Flex, which are both browser-based technologies. Flex applications run in a small browser plug-in, while AJAX just runs in the browser. Did the Eclipse community hijack the term?

One day I was composing an email, using Yahoo, which is a browser based interface, when I noticed that about half of my words had squiggly red lines underneath. What's all the red, I wondered? I tried clicking on one of the words and was immediately rewarded with a small popup list containing similar words, but having correct spelling. It turned out that some asynchronous process in Yahoo was running a spell checker while I typed.

Now I'm really wondering just how far AJAX will go? Will it be possible to deploy applications to servers that provide desktop like interactivity, without the need of a footprint on the desktop?

Nathan.

Nathan, thank you for your comment.

Tools and technology mature. When a new technology enteres the market there is a lot of hype and initial enthusiam. Often the new technology doesn't live up to the expectation. This is not a new pattern. The client - server model fell into that trap, and not just on the System i. Bad initial experience, even failures, does not justifying writing off future generations of the technology "because it didn't work before." AJAX is the beneficiary of a long line of bad experiences and failures in web enablement.

In terms of size, "fat" is relative. I don't think "fatness" should be judged on absolute numbers. The judgement should be made by comparing the client's size and resource consumption:
- to the size and resouces of the client system, and
- to the performance that the client application delivers in exchange for the resources consumed.

The term "rich client" is a generic term can be used to described any client with a signifcantly improved interface. Since its inception in 2001 Eclipse has described itself as "an open extensible IDE for anything and yet nothing in particular." In 2002 developers began to recognize the potential for developing non-IDE applications using Eclipse. This is when the first internal position papers for a subset of Eclipse plugins to develop non-IDE applcations emerged. The first "announcement" outside the Eclipse community of the Eclipse Rich Client Platform (RCP), which I have located, was the November 11, 2003 integration build of Eclipse 2.1. The copyright year of the RCP examples in the next blog entry is 2003. I personally encountered Eclipse RCP in mid 2004.

So no, I don't think the Eclipse community hijacked anything by naming this project Eclipse Rich Client Platform.

I agree, complicated applications which were once only implemented as client server, for example e-mail clients, are now successful web applications.

I also am interested in seeing how far AJAX will go.

My point, though, is that the client server model is still relevant for some applications in some sets of "circumstances," those circumstances being the confluence of hardware, network structure, number of users, types of clients and more.

Yes, in many situations the nature of the application and confluence of circumstances support a web deployed GUI access to System i resources or applications.

But not every time!

I believe that the client - server model has evolved just as the web enabled, and web distribution models have evolved. In this blog I want to explore the potential of one particular means of implementing the client - server modle, Eclipse RCP.

For a given application and environement the best choice may be a client - server application. I hope to show how Eclipe RCP can be applied and provide a place for other people using Eclipse RCP on the System i to share their experiences.

Again, thank you Nathan for giving me the the opportunity to say this. I hope we hear from you again.