Contents
Cloud J
- It's an interpreter, it's a session,
- it's a rich media transcript, it's an executable workbook,
- it's literate, it's like a wiki,
- it's collaborative, it's concurrent,
- it's an extensible framework, it's a widget platform,
- it's a versioning system, it's a continuous integration,
- it's a package manager, it's a IDE,
- it's in the browser, there's no installation,
- it's always available, it's in the cloud,
- it's Cloud J.
Client Side
You don't have to install anything on your device--yes, not only desktop, but any portable gadget with a decent browser. The client is browser-based, so it is always available wherever you have an internet connection. (For no internet connection, there is a local mode, depending on the platform with or without the session.)
It looks, feels and functions like a web-based email client, yes, much like Yahoo! Mail or GMail. You log in, which opens the main screen with three main views: a (folder) browser, a live session and a script editor. Between logins it remembers your open scripts and contents of files; however a new session starts with each login.
The exact layout of views depends on a particular platform (mobile or full). For example, in the full mode, it is a three-pane layout with the folder browser on the left, the script on the top and the session on the bottom; for mobile, there is one view per screen which slides back and forth like iPhone Mail.
The web client is of the rich Ajax type, so it provides highly interactive experience with small efficient exchange with the server. Together with the session running at the server, it creates a rich client-server environment, where the server does the processing and returns data packages, and the client renders the presentation to the user.
Session
The session view is the transcript of interaction with the interpreter (commands and responses).
Each time you log in, a new interpreter session is created on the server, which lives as long as you are logged in.
When you type a sentence in the session view and press Enter, the line is sent to the server, which evaluates it in the interpreter and sends back the result, which is appended to the transcript.
Rich Media Transcript
Unlike the old J session, which only supports text, the session transcript can include, as part of the result, various rich media fragments, such as images, plots, 3D pictures. It could be dynamic (like animation) or interactive (sliders changing the picture) or even sound and movie clips.
Executable Workbook
Transcript paragraphs are highlighted based on their type: input, response, error, comment, media, etc. They can be edited, rearranged, re-executed. Transcripts can be saved, re-opened, merged using a round-trip format, which can also be sent by email or attached to a Wiki page or become a Wiki page. Thus it can be used as a Mathematica notebook. It can also be played step-by-step acting as a lab. Collectively these features can be referred to as the Executable Workbook.
Widget Platform
The widget platform allows more interaction and richer UI than the session transcript. You can create pop-up windows, fill them with controls, send events to the server, which in turn will modify the form widgets, data etc. The WD interface could very well be supported.
Debugging
You can set breakpoints and enter a server debugging mode, which will be projected to the client showing the current step, variables, etc.
Script Editor
The script editor can open one or more files in tabbed (or drop-down selected) view. There may be syntax highlighting, line numbers, breakpoints, etc.
Any changes you make are saved at the server and versioned.
You can run portions of code from the script--current line, selection or the whole script--in the session view.
The code could be further improved if it was edited in literate format, so that it could be formatted in typeset form with illustrations, links etc. and integrated with the Wiki. (A separate file extension could signify that.) In fact, it could be a format much like the rich-media transcript.
Browser
The browser has a number of views, which are toggled with an icon bar.
Folder Browser contains folders and files in the common and user areas. Since all scripts are versioned, this is also the view of the HEAD of the versioning system.
Resources other than scripts can be uploaded and downloaded from the folders.
Version Browser is like the Folder Browser, but with the ability to view file versions and other branches. It is the Time Machine of the script storage.
Locale Browser shows names and values in the locales of the current session.
Project Browser One possibility is that there is no special project view. Instead, a project is a file within any folder, which has targets--for example, run, test, etc. Note: there are no builds or target scripts per se.
Server
The server consists of * request dispatcher, typically a web server like Apache * child J processes for each session * versioning system * folder layout on disk for file storage: common and user-specific
User navigates to a login URL, which on successful login will spawn a J process, which will process all subsequent requests for that session.
Some of the old file and I/O handling need to be modified in the way requests and responses are handled. The file storage needs to be split between common and user areas, synched with the versioning system at certain points.
Some of the output commands like plot, gl3, viewmat, etc. instead of creating pop-up windows will generate images and merge them into the rich media transcript.
User Profile and Permissions
Each user must be registered on the system, have system permissions and the session must be impersonated with that user. That way it is guaranteed that file permissions and disk quotas are observed. In other words, the client-server runs as if the user physically logged into the server with ssh and runs a session there.
The session will also be bounded by memory and time limits.
Single Source of Truth
In Cloud J there is no such thing as source and target scripts. There is only one location of script; what is edited is what's loaded. So there is no build.
This could be further reinforced if module and/or script names reflected the locales where the names are created. Cf in Java, package and class names correspond to the code folders and files.
There is no Package Manager either. There addons are already and always part of the system and can be browsed directly in the folder browser.
Script Storage
Scripts are stored on the disk on the server, versioned into a versioning system (SVN).
There are such script areas:
Common Area includes addons, base library, framework, etc. This is the system itself and modules of common interest (addons). By making the system amenable to direct modification turns it into a sort of collaborative Smalltalk environment.
Quarantine is a user-specific sparse mirror of the Common Area with only those files which are edited by the user and not committed to versioning. This is to ensure atomicity of commits and system stability. The physical location of files in Quarantine is managed by the system and is transparent to the user: when the script is loaded, the same path is used as to the common area--again the Single Source of Truth principle.
Personal Area is equivalent of '~user/...' folders and files. Physically, these are 'user/username/folder/...' and for each user the value of '~user' is assigned individually, so its '~user/folder/...' when session starts.
Users may choose to mark certain files as available to others.
Loading Scripts
Scripts from the personal folder are always loaded directly.
Scripts from shared folders are first sought in the quarantine location and then in the common area. Thus the user can always work with a personalized view of the system, even before the changes are committed.
Versioning
The personal files are saved directly into your personal folders (~user/file.ijs), and versioned at the end of the session or upon request.
The common area files (which you have permissions to edit) first are saved to a temporary "quarantine" location, which are "committed" in an atomic submit transaction, and versioned and this point. Once the shared files are committed, they are available to everybody next time they load them in their sessions.
Milestones
After a series of iterative modifications, the system reaches a next level of features, which makes sense to freeze in time for a point of reference. This is called a milestone and it may be planned ahead with a set of particular features and target release date. In particular, in case of catastrophic failure like badly breaking code, or a disk failure, as well as when a system needs to be replicated into a new location or branched, a particular milestone can be taken as a restore point.
A Milestone is done by freezing the Common Area for updates, running necessary tests and when satisfied, tagging the area in the versioning system. A distributable archive can also be created at this point.
Individual addons can be milestoned individually and separately from the "base" library.
Request Handling
Since HTTP protocol should not keep the connection open, the subsequent requests will be accompanied by a session ID, which will correspond to the J process ID.
The channel between the dispatcher and J process can be different. For example, the dispatcher identifies the J process by the HTTP header (cookie) and passes the socket to the J process, which "wakes up" and handles the rest of the HTTP request, sends the response and closes the connection; and so on for each request.
Discussion
Place your comments here -- OlegKobchenko
- ...