Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support distributed storage for REPL sessions #8

Open
Tracked by #1
oubiwann opened this issue Mar 13, 2024 · 3 comments
Open
Tracked by #1

Support distributed storage for REPL sessions #8

oubiwann opened this issue Mar 13, 2024 · 3 comments
Labels
Milestone

Comments

@oubiwann
Copy link
Member

oubiwann commented Mar 13, 2024

Core capabilities:

  • Manage configuration state
  • Manage session $ENV

Might want to just start right off with ETS ...

@oubiwann
Copy link
Member Author

I actually decided to start with Mnesia, in particular, a kv wrapper for it.

@oubiwann oubiwann changed the title Create an LFE gen_server that can manage a REPL session Support distributed storage for REPL sessions Mar 14, 2024
@oubiwann
Copy link
Member Author

The REPL state record has these fields:

  • curr (current environment)
  • save (pre-slurp save)
  • base (new env, but with all the predefined functions, etc.)
  • slurp (a boolean flag)

I'm going to want to track additional data ... maybe the following?

  • id (generated, should be treated as read-only)
  • module (unique name; might map to actual modules, eventually)
  • created (timestamp)
  • updated (timestamp)
  • sessions (a list of maps, maybe? all the currently connected sessions ... type, pid, host, etc.)

@oubiwann
Copy link
Member Author

Notes from Discord this morning:

btw, I'm going to be experimenting with a mnesia-based kv store for the REPL ... in particular, I'm going to add a handful of new fields to the REPL state record to assist with both querying and easily swapping different user ENVs; once the experiments pan out, I'm going to:

  1. intercept existing adds and updates to the REPL env -- this will "convert" the LFE $ENV var to "temporary storage" and make mnesia the source of truth for REPL state
  2. add some convenience functions that will allow users to create new ENVs and easily switch between them in the REPL
  3. if all this goes well, I'm going to see if I can completely remove $ENV, replacing calls that use it to query mnesia instead -- this will be the first use case that will take advantage of decoupling state from the interactive REPL
  4. if that goes well, I will then work on remotely creating REPL sessions and sending eval queries from another node -- fixing any issues that come up and iterating on a good user experience / API for this

at that point, we'll be able to start experiments with stdio access (e.g., piping to and from a process), connecting via SSH, creating a REST server, an ETF-based protocol for using the REPL remotely, and finally explore the possibility of implementing the nREPL protocol

btw, I don't want to limit the number or type of simultaneous connections to the xrepl server, which is why I've started with mnesia and multi-environment support as the foundation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant