traditional programs vs fastn "execution model"

[amitu]

In most languages, eg Python, C, Java, the application runs as an operation system process, and has access to std-env, environment variables it inherited from parent, command line arguments, standard input, stdout, stderr and other inherited file descriptors.

Users interact with applications either via shell, or applications launch a web server, or they create a user interface. The programming you have to do for the three are completely different. The stdout/in etc can be considered part of application interface, the operating system + shell takes care of wiring the data / creating file descriptors etc.

For HTTP service one has to explicitly (via in most cases via some libraries) listen on some port, handle each HTTP request. In case of language like PHP, this is taken care for you, the way shell takes care of managing stdout etc for you for a typical C process. You can argue PHP program is not a program in same way a C program is a program, and PHP is a module loaded by mod-php or some such in another application.

Similarly when you are creating a re-usable django application, you are not really creating a program, and it's embedded in another bigger program. Django project manages the HTTP, and applications are responsible for registering URL handlers, and Django calls the registered functions defined in URL handlers when HTTP request comes.

From the django application or PHP point of view, the execution happens on HTTP request level, each time a HTTP request is called, application life cycle is executed. Same happens for other HTTP containers like Tomcat in Java.

So we have tradition execution model, where application is invoked by user using the shell, or we have HTTP containers, where things are called as response to HTTP requests. We also have graphical applications, that are launched by icons on Desktop / Application Launchers, and while they may have access to tradition application constructs like command line arguments, environment variables, stdin/stdout, the UI application interact with user via user interface, user sees a window (or maybe application presents no window, and listens to keyboard / mouse events or watches screen etc).

So we have three execution models so far. "shell application", "http application" or "GUI application".

fastn represents a sort of hybrid execution model, where every fastn program is all three of them at the same time, and it depends on how you are running it, or how are you interacting with it. The application itself is written in an agnostic way.

Command Line Arguments, STDin/out etc vs fastn's HTTP--

In regular shell applications, an app has access to arguments, environment, stdin/out. fastn programs do not have direct access to these things. fastn applications have a HTTP minus minus interface, so e.g. you can say:

fastn /

Here you are accessing the "URL", /.

Since you are running the fastn binary on shell, it must run from inside a fastn application directory. If you want to run it from another folder, you can pass -a <path-to-application-dir>.

The URL is the main argument. Based on the URL, fastn does folder based routing, along with dynamic URL routing, to find out the .ftd file that has to be invoked.

Normal applications have access to command line arguments, env, stdin etc, fastn apps have access to "input". All input in fastn is key value data, where value is a serialised JSON like data, and fastn is strongly typed language, so when accessing any input, it has to be bound to a typed variable in fastn, and JSON has to cleanly deserialise into that type, else this is application error. Application can chose to handle this error, or fastn runtime can reject the request.

So when interacting with fastn in shell, it still acts like HTTP server, but it does not open any network ports, the command line arguments, stdin, env are accessed as input.

The Output

Typical shell applications either have stdout/stderr based output, or they can take over the tty, like vim, top etc. The output of a fastn program is a user interface descriptor, which can be be serialised and written on stdout, if that is what is requested / that is what fastn program wants to do, or it can take over the tty, and keep running in background. The same user interface descriptor is rendered in terminal / curses mode, and it can allow user to interact with the program by following links, filling forms, scrolling etc.

GUI Mode

When running the fastn application, one can request GUI using --gui, or maybe the application is written in such a way to always present UI. In this mode a native UI window will popup, and same user interface description will be used to create a graphical user interface. The user interface can be interactive, with links, forms etc, which user can then interact.

HTTP Mode

The fastn application can also be started in HTTP mode, in which case the command line path is ignored, and a HTTP server is started, and user can open that server, and it shows the user interface using HTML/CSS/JS, and user can interact with it using links, forms etc.

Mobile Application Mode

The same fastn app can be compiled as an iOS or Android app, and users can use it as mobile apps.

Interface Agnostic Code

The fastn application is written in such a way that it does not care what mode is being used to interact with the application, it runs in terminal-stdout, curses, GUI or HTTP mode.

In each mode the fastn program can opt in to specialise its behaviour, e.g. use platform specific user interface component, or it can chose to use standard ui elements, which work on all supported targets. The standard UI has platform specific implementations, so it optimally uses each platform's capabilities.

Same user interface specification will not look exactly the same on all platforms, but it will largely look the same in User Interface modes, and will have same behaviour / layout in curses / terminal mode.

Reduced HTTP Language

The interaction uses HTTP terminology, there are path, there is method (only GET/readonly and POST/readwrite), there is input, there is cookies, maybe headers (mostly trying to avoid it), there is Ajax equivalents.

URLs mostly present a view, which is a UI description, which gets rendered in platform specific way. The view has local event handling, local state etc. And view can interact with the "server" via ajax/reduced-http.

URLs can chose to also return JSON, or other content types, or chose to return "redirects", "not found", "server error" etc.