The Browser as a Client

For all of my 25 year career I have wanted to develop platform independant shrink-wrap software. Technically this has been possible for some years now by writing in Java, Perl or Python - with the latter two using TCL to provide a GUI. I resisted this approach for a number of years because:

• For less than practical reasons I was not happy with releasing interpreted code.
• It's inconvenient for the end-user.  None of the interpreters or virtual machines come stock with the operating systems, so the user has to locate these themselves.
  
• Java is the only language that has IDEs to help lay out visual components.
• Most users consider the GUIs produced for Java, Perl or Python software to be a little strange, simply because they aren't native.

As you've probably gathered, one of my most consistent problems has been with the GUI. Admittedly Swing has improved out-of-sight and Eclipse is providing a competitive cross-platform system. Long before either of these alternatives became available I had decided to use a DHTML browser as the front end for the Adept Software Development system. This is something I stand by, too - a DHTML browser of some sort is native to every operating system, is hardware independent, and is an interface that most users know like the back of their mousing hand.

Advantages of The Browser and GUI

• There are plenty of powerful tools for creating outstanding and variable user interfaces.  Any recent HTML editor, in fact. Web designers are entirely familiar with the necessary tools and can provide quality interfaces far beyond those that require a developer to create..
• Familiar user experience - even a user who might feel totally lost within the Java Virtual Machine is likely to be able to handle their browser of choice.
• Full access to the rich media the browser provides natively - including (but not limited to) video, images, PDF, Javascript, Macromedia Flash/Shockwave and Java applets.
• The GUI is only loosely coupled with the server, so changes to the visuals of the interface are non-destructive and simple - often accomplished by simple changes in the style sheet.
• DHTML techniques allow the designer page to be used without change. This means that the designer can update pages without a developer having to go back and translate it into production code again.
• The web server design is inherently multi-user. This means you can run applications at home, access them at work, or provide the tools and data to your workgroup.

Disadvantages of The Browser and GUI

• The browser is great for multi-media and form based work. It is not as suitable for complex interactive programs similar to word processors or spreadsheets. Of course there are many good plugins (Java Applets or Native Active-X components) that will fill many of these types of tasks and still work well with Adept.
• Many believe that HTML, DHTML, XHTML and XML do not provide the best in GUI design. For those with this viewpoint, Adept is a less useful tool.

Requirements

I have developed the Adept Development system for my own learning and for my own used. I set the following goals:

• Make no compromises. I develop the software to my best ability without compromising quality. I've had my fill of working on projects where time and money overrule the principle need for good design and code.
• Must be fully documented. I provide ongoing full documentation as part of the code - line by line - and keep it up during updates and changes.
• Full Unit Testing at all levels. Unit testing is a concept I've embraced, and I want to see how it fairs when fully implemented.
• Use Browser/DHTML as the front end to make full use of the talents of the modern GUI designer. It is popular to criticise the browser as a client, but I believe the advantages outweigh the problems.
• Must be inherently multi-user. The application server/browser framework allows for more than one user. I see no reason why this shouldn't be implemented to provide the same conveniences to the single user.
• Must be cross-platform. It has always been part of my vision to provide the same software on Windows, Mac and Unix/Linux, without having to spend costly months on ports.
• Implement separation between the GUI and back-end so that a HTML designer can continue to work on production pages without referring to development staff.
• Follow correct architectural principals to divide application development up horizontally (separate tiers) and vertically (clear functionality packages).
• Be able to be compiled by a native compiler such as GCJ to provide shrink-wrapped packages of software for each platform.
• Not to rely on server based database systems such as Postgres - although the users of the system should be free to use these if that is their desire.
• To work on all modern DHTML compatible browsers - Microsoft and Mozilla/Netscape based, as well as on OSX browsers like Safari.
• To provide clear and useful session management - including the simple retrieval of session and conversation data without having to explicitly pass them through the tiers.
• To provide a system that can be easily used by corporate developers - with the tools, packages and techniques that are familiar to them - to create shrink-wrapped software packaged to give away or sell.

Introduction

My name is Paul Marrington, software developer. Well, just Paul Marrington, actually. The software development part, as you might have imagined, is what I do. Before you join the other 99% of visitors to any given web-page, why not take a moment to hear a story that has a good chance of hitting close to home.

I joined the software industry in its infancy, and by the early 80's I was spending my time exclusively developing software for myself and my customers. I was among those who saw the merits of micro-computers before they became mainstream, and so the PC was my bread and butter for many years. Shareware was the word of the decade, and each person owned themselves.

But - and this is the part that might sound familiar - a family and the necessities of life forced me to realise that the only customers who could afford to consistently support developers in their trade were the corporations, and so I joined the queue and was contracted out. For the last six or seven years my primary source of income has been working as an architect and development manager for corporate client/server systems - the mainframe'd masses - and it scares me how easily I joined their ranks, and how quickly my skillset began to be molded exclusively fit the Information Systems model.

However, working as a corporate development manager I came in contact with many developers who were highly interested in application development, and I came to see that a great deal of client/server architects would be developing shareware and freeware for themselves, if they could use the same techniques and tools that they were used to.

I've also watched designers develop HTML pages for the business to sign off and give to developers to be converted into xSP (JSP, ASP, PHP, etc) for implementation. Not only does that mean developers are wasting time in the conversion but more importantly, the designer cannot easily change the interface as the customer's needs change. I like the idea of the web page signed off by the client going into production with little or no change. That way the GUI designer can make visual changes without interference from development.

So, wanting to try my hand at application development again, and hoping to eventually provide the same opportunity to my colleagues, I decided to create a system for enterprise developers to be able to create shrink-wrap systems. Adept (Application Development - Enterprise to Personal Transformation) was born. I have divided my development efforts into two source trees. There is a support library in com.marringtons.library, while the Adept specific code is in com.marringtons.adept. See Adept Open Source Library for the blog on the support library and Adept Software Development for general discussions on software development.

The Adept Development System is specifically designed to leverage developer tools, libraries and skills to provide shrink-wrapped products. Put simply, if you want to use the skills, tools, etc that you use in your corporate job to create software to give or sell to friends and clients, then Adept will provide you with what you need. That still leaves the question: so what is Adept, then? The simple answer is a personal web server designed to fully utilise DHTML to provide a truly integrated client/server system using a browser for the GUI.

Benefits of the Adept Approach

• Well known GUI and tools using the modern browser of the user's choice.
• Full access to the rich media the browser provides natively - including (but not limited to) video, images, PDF, Javascript, Macromedia Flash/Shockwave and Java applets.
• GUI is loosely coupled with the server - allowing easy change of look and feel - often by changing the style sheet.
• HTML Web designers are totally familiar with the tools and can provide a depth and quality of interface far above that of any GUI that is created mostly by a developer.
• DHTML techniques allow the designer page to be used without change. This means that the designer can update pages without a developer having to go back and translate it into production code again.
• The web server design is inherently multi-user. This means you can run applications at home, access them at work or provide the tools and data to your workgroup.
• Client code can be written in JavaScript, Flash, VB or even Perl if you are willing to install the Perl plugin and use IE. You can also use activeX, Java applets or other mechanisms to provide a rich client. The basic system requires only Javascript to be enabled - and Javascript is available natively on all platforms.
• Adept Server code is written in Java and natively compiled using GCJ. This allows additional server code to be written in Java, Groovey, Python (using Jython), Javascript or any of the miriad of other languages supported by the Java platform. See this page for examples.
• Java has a rich source of libraries for every occasion from many sources. There are libraries to serve MPEG, render PDF, process XML and just about any other task you can imagine. Many of them are open source.
• Adept provides a server push technology to allow the server to update the client display when the server finds a reason.

Limitations in the Adept Approach

• The browser, and hence Adept is great for multi-media and form based work. It is not as suitable for complex interactive programs similar to word processors or spreadsheets.
• Many believe that HTML, DHTML, XHTML and XML do not provide the best in GUI design. For those with this viewpoint, Adept is a less useful tool.