This page contains design goals and discussions for the Tcl Application Server whose development is beginning as part of the Google Summer of Code (GSoC) project. It is realistic not to expect all of the goals to be met by one person in one summer.
In the initial discussion of this project it became clear that different people had different definitions of what an application server was. This section of the Wiki page is intended to review those definitions then define what is meant by application server for this project.
The definition used on the project is similar to what the Java folks mean when they talk about an application server[L1 ]. For this project we will be talking about two related definitions:
For this type of server, the application runs partially in the server and may run partially elsewhere. Generally there are three types of UIs:
Light Weight
The user interface is rendered in HTML. The generation of HTML currently has a well defined and well received Tcl level API in the HTML package of TclLib.
Medium Weight
This approach to user interfaces uses JavaScript or the Tcl Plugin to implement the UI running in a bowser on the user's computer.
While the Tcl Plugin would seem to be the most desirable and easiest road since the implementer presumably already knows Tcl/Tk, or at least only has to learn one language. The reality is that there are several negative aspects to this approach:
The above considerations greatly reduce the deployability of "applications" that use the Tcl Plugin.
Now lets consider JavaScript. It has the following advantages:
However it has the following disadvantages:
However, there appears to be something that offers the best of both worlds Æjaks. This allows the programmer to learn Tcl/Tk and the Æjaks API (which is similar) to Tk to program an application. The current (drawback|feature) is that Æjaks currently only works on Java Application Servers.
Heavy Weight
This is sometimes also called 3-tier or n-tier approach. In this approach sever levels of servers may be used (database, web services, application code/update server). The GUI is implemented by a Tcl/Tk program that the user installs and runs locally that communicates with a database or web services server. Where application server comes in is to serve up the code and/or updates to the code to be run locally. Depending on the design model chosen the Tcl/Tk program that the user launches may be very minimal and be just enough to download the actual application every time it is run. A variant on the previous model is to have the use launch a very minimal that access a local cache of the actual code and checks the server for any changes to the code before running the actual application. If changes are discovered, they are downloaded to the cache and the actual application then run from the cache.
This section list the long term goals of the project. As goals are meet, please mark them with the word "Meet". Items with a (1) refer to a goal that applies to Supplier of Web Services. Items with a (2) refer a goal that applies to Supplier of UI for Web Services. Items with a (1,2) refer to a goal that applies to both.
It is strongly suggested that the packaging mechanism be a Starkit. Starkits are widely accepted as the de facto standard on packing Tcl/Tk code.
The project will use WS::Server and WS::Utility APIs to define Web Services. The API may have to be extended by the project.
A specification similar to WS::Server needs to be created, but can be much more light weight since type information may not be required. It may be very desirable to separate the processing from the formatting of the output (i.e. allow multiple forms of output). This may actually resolve into multiple specifications, e,g. one for HTML form/argument input and another for Æjaks.
An example of a simple specification for HTML form/argument input may be:
UI::Server::Service ServiceName UI::Server::Proc ServiceName ProcedureName ArgList Body
where ArgList is a list of argument names, the last one can be args. Form/input elements are mapped by name to the arguments, any remaining elements are passed to args as a dictionary.
This section list the long term discardable goals of the project. As goals are meet, please mark them with the word "Meet" and move it to the Goals section. If it is determined that a goal can not be meet, move it to the Non-Goals section.
Initially this is a bulleted list. As a details are provided on a goal, please move it out of the bullet list and place it after as a Header Level 2 item.
This section list the non-goals of the project.
Initially this is a bulleted list. As a details are provided on a goal, please move it out of the bullet list and place it after as a Header Level 2 item.
This section will be filled in as the project develops.