Implement per-session environments

[oubiwann]

Whenever a new client IP address issues an eval request, a new session would be created and managed (see #8). Each session would get its own environment, allowing try.lfe.io users and *.lfe.io applications to define variables, functions, etc., and call those in their session.

Possible implementation: we could store a user's LFE environment in mnesia, key'ed off the md5 of host. Then store function and variable definitions, and perform lookups on a per-session basis.

This would mean that 100s or 1000s of users wouldn't have as big an impact on the system; we'd just need to set up mnesia.

Tasks (these are old and need to be revisited, per the description edits/updates):

• define record with "hash" key and "data" key (for now, just use the md5 of the IP address; when Create a modal dialog when the page loads #15 and Create md5 hash from username #16 are done, we can use the username too)
• define ETS table
• add wrapper functions for insert, get, delete, etc.
• query command state table when eval'ing expr from user
• save command state in table after successfully eval'ing expr from user for re-use in the next call; this save should over-write whatever data was associated with the user/ip hash key
• see if function definitions work
• see if +++ and *** work
• every time a user executes a command that goes back to the server, the expire time should be reset

[rvirding]

These three issues, #8 #9 and #14, are really three sides of the same problem so I will write once and copy and then we will see where the discussion goes.

• It would be quite easy to open the LFE shell and provide externally callable functions to process commands. run_string and run_script almost do that today.
• You would then write a new top-loop using these functions.
• This would not solve the problem of input/output when processing the commands, they by default send to/read from standard_io.

An easier way might then be to use the existing shell but to reset where the shell's, and the processes it starts, standard_io to control input/output. You then automatically handle all io in the commands. This is actually very easy to do, an example*:

http://www.geekherocomic.com/2008/11/12/real-programmers-dont-write-documentation/

This can also make the shell manager easier. The real question is then how we want to interface the "shell".

• This is also a good example of how versatile the io system really is. :-)

[oubiwann]

Hrm. This is an interesting approach. It would actually be quite nice to have the LFE shell become more of a usable tool for the management of LFE code (in both foreseen and unforeseen uses ...)

[oubiwann]

With change ec27902 I've prepared things for saving env/state data. Since the data will be keyed off of user+client host/ip, I think ETS should be fine, yes?

In which case, we wouldn't need mnesia, and I can explore saving and reading the env data to ETS for each call so that (set ...), function definitions, etc., will work.

[yurrriq]

Might be cool (or unnecessary) to keep track of the users last few calls in ETS too, to enable the + features in the REPL. Maybe that would just work out of the box... Could keep track client-side too/instead and enable an ⬆️ or M-p sort of feature.

[yurrriq]

A good example of the client-side behaviour is the RethinkDB web interface.

[oubiwann]

I brazenly copied (with credit) the JavaScript from Try Clojure (
http://www.tryclj.com/) -- and with the jquery-console library it users, we
get history, a la readline, for free :-) (until a page refresh).

However, in my few experiments so far, I'm guessing that we'll get
+++, etc. for free as well, since I believe this gets looked up in the
env.

I'm actually kind of excited about seeing this in action :-)

Thanks for pushing us to do this, Eric!

On Thu, Aug 20, 2015 at 11:56 AM, Eric Bailey [email protected]
wrote:

Might be cool (or unnecessary) to keep track of the users last few calls
in ETS too, to enable the + features in the REPL. Maybe that would just
work out of the box... Could keep track client-side too/instead and enable
an ⬆️ or M-p sort of feature.

—
Reply to this email directly or view it on GitHub
#14 (comment).

[yurrriq]

Sweet!