In the old days, we used to use dumb terminal for Input/Output. Things went crazy and now we have the whole web infrastructure and all its crazy complexity.
I want to use Elixir and Erlang for all its wonderful features, however, I do not want to use web interface for my user interface screens. I can use normal dumb terminals.
I cannot find any information on how I could implement dumb terminal infrastructure for Elixir/Erlang.
My development would be much more robust with WYSE terminal infrastructure and I do not have to bother with web interfaces.
Looks like fully blown TUI, I don’t think that artificery can help you there…
I’m not aware of any TUI frameworks, but perhaps you can use ex_ncurses to build one.
Alternatively, just write your Erlang/Elixir app on the server and the usual C, rust, python or whatever dumb clients displaying the data received from the server.
The can communicate via HTTP or any other protocol you like.
I decided to try the ratatouille getting started guide. In the installation section, it says to add ratatouille to a mix project’s dependencies. But, then how do you run the counter code, which I put in lib/counter.ex? $ iex -S mix doesn’t do anything. And, I get a file not found error with $ mix run counter.exs.
Thank you all for the replies. Clearly this is something that is not done anymore.
It looks like Elixir environment is not the way to go for this project.
I will have to go the IBM AS400 or IBM AIX route with COBOL and DB2 and think clients or terminal emulators so that I can remove the need for web servers.
“COBOL”? That seems pretty over-the-top, considering the perfectly good suggestions you’ve gotten here.
And, while I don’t understand the antipathy to “web servers”, you can certainly deliver plain text content to a “dumb” Wyse terminal using a text browser like Lynx.
The application environment is technologically challenged. Not enough developers or money to support 3500 sites, where the sites use the bandwidth for Internet browsing instead of doing the companies work. The solution needs to be deployed on minimal computing components, the less moving parts the better. So web servers just add an additional layer of complexity that is not needed for the server and data capture that is done at the 3500 sites. I need a robust environment where users obtain uninterrupted service from dumb terminals or featureless PCs that just present a login screen when started up and login to a single central application. The application screen can be served up even with a 9600 bits/sec modem.
I don’t really understand what you’re saying here, but consider that some server/process has to receive terminal input, marshal the data and format the terminal output.
No I describing an online banking application for 3500 branches. TODAY
I can understand knowledge of this computing paradigm has been lost. The glamor and sexiness of web applications has pushed this old tech to the scrap heap.
But it worked, and still has a place today.
I will keep looking, maybe someone in the community remembers how to do something as simple as this.
In what way doesn’t ratatouille satisfy your requirements?
Is it that it uses a declarative, HTML-like View DSL rather than supporting CICS-style Basic Mapping Support (BMS)?
Things went crazy and now we have the whole web infrastructure and all its crazy complexity.
At this point in time you clearly want a human interface but for machine-to-machine interfaces where
It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. For example, it has been used in sensors communicating to a broker via satellite link, over occasional dial-up connections with healthcare providers, and in a range of home automation and small device scenarios
I could be wrong, but I think Ratatoulli presents one user interface per OS process, to the tty invoking it. It isn’t providing a terminal server. I think what OP wants, is something like Ratatoulli that you can SSH into directly. Erlang has a native SSH server and Ratatoulli is very close to what he needs, maybe it could be made to work.
The screenshot looks like a curses/ncurses tty application. Unfortunately there are very few languages that currently bind with the ncurses library, besides C/C++, with ongoing support. You would have more success starting at Python, Perl or Golang.
The BEAM is very server-centric and favors distributed, concurrent applications.
As he mentioned banking, I do think its even worse than that…
My sister works for a bank, and even though most work places are using thick clients, there are some thin clients left (and to be honest, the thick clients are basically running an emulator that mimicks behaviour of the thin client).
I’m not sure if any curses implementation can handle this.
Thin clients is not necessarily something modern software design would consider in the way it is presented here, as the last time I have rolled out thin clients to a company, it were basically hardwired installations an RDP client that connected to a central server that ran windows for the clients…
