What should we put in the server component?

So, Shae wants to build a multi-user browser-based Haskell interpreter.

The big question is: how do we distribute the functionality between

  • a server in the cloud
  • the user’s local machine
  • and the web browser window?

For instance, one option is to have a server that performs the evaluation of Haskell expressions. The problem is that this necessarily restricts the language dialect that we can offer. In particular, a server has two main restrictions: security and resource usage.

It looks like we have four options:

  1. A public cloud server that evaluates Haskell expressions. It can be used by anyone. Existing examples: lambdabot, TryHaskell. We have to deal with security and resource usage. The state of the art for security is to use a module whitelist and SafeHaskell. For resource usage, calculations will have a time limit and the interpreter has to be stateless, i.e. you can’t declare new variables at the prompt.
  2. A private cloud server that evaluates Haskell expressions. To use it, you first have to create an account. This way, we can offer basic persistence and we have restricted the audience to an extend that we don’t have to worry much about resource usage.
  3. Evaluation of Haskell expressions is done on a user’s local machine. However, the new thing is that a user can share his session and code with other people on the internet. Of course, he retains full control over what is being evaluated on his machine. This solution is much in the spirit of a multi-player game session, where one player’s client turns into a server. A public cloud server can be used for “match-making” and NAT tunneling.

After some discussion, we found the third option to be the most appealing: we can offer the full Haskell dialect. Sooner or later, learners will have questions about Haskell in its full glory (IO, file system, parallelism and concurrency, …) and then we would be back to using hpaste. Furthermore, the administrative and coding overhead for the server is somewhat reduced.

What does the Haskell community think? Do you think that this is a path worth pursuing? Let us know in the comments.

Note that we want to start with a prototype interpreter running on a local machine anyway. But we still have some time to decide in which direction we will take this.
I didn’t mention the fourth option yet, because that one is a little wacky.

  • 4. A public cloud server compiles Haskell to JavaScript and sends the JS code to the browser window. This immediately solves both the security and the resource usage problems. Unfortunately, since GHC doesn’t support compilation to JavaScript yet, it still limits the Haskell dialect, though in a different fashion than SafeHaskell does. It would be possible to use the Utrecht Haskell Compiler with the JS backend, though.
This entry was posted in Uncategorized. Bookmark the permalink.

8 Responses to What should we put in the server component?

  1. Alexander says:

    The user must have ghc, or anything else on the local machine?

  2. Jonathan S says:

    Option 4 is actually viable with GHC because it supports a LLVM backend. Simply compile the code to LLVM, run it through Emscripten (https://github.com/kripken/emscripten), and get your javascript. This has a number of advantages. Firstly, as mentioned in the post, it solves the resource and security problems automatically. Secondly, by using GHC, we get the same error messages people will be getting on their home machines. Thirdly, Emscripten supports many standard libraries, so you could actually test programs that use things like OpenGL. Lastly, you get the same performance characteristics as the actual GHC – the same optimizations are run, etc.

    • Heinrich Apfelmus says:

      Well, this particular option is not viable in the sense that nobody has done it before. GHC has a complicated run-time, you can’t just call emscripten and hope that it works. For instance, how do you implement concurrency support? That’s why I think that this is beyond the scope of this GSoC project.

  3. Option 3 sounds cool, but seems likely to be too ambitious for a SoC project (at least given my experience with SoC).

    I would argue that a lot of the time you do not even need to evaluate Haskell code, type checking already goes a long way. For a simple prototype of that approach (Option 1 in the table above), see http://haskellonline.org , a weekend project of mine.

  4. qelt says:

    Option 3 does move the security problems to one of the clients’ machines. I don’t think we’ll have many outright trolls waiting around on IRC for an occasion to paste “import System.Directory ; getHomeDirectory >>= removeDirectoryRecursive” into a noob’s session, but I’d still feel uneasy if it were possible by default.

    Even with option 3, giving access to “Haskell in its full glory” still doesn’t look like such a good idea.

    • The idea is that only the user running the server may actually initiate evaluation, the other users can only make suggestions. In other words, they have no direct control over what is being evaluated on the user’s machine.

      Still, this turns security merely into a question of social engineering (obfuscation, persuasion, …). Then again, executing some code you found in a hpaste is not without problems either.

  5. Option 3 seems to provide the best user experience: performance is better and it’s more expressive and complete. It can be implemented as a browser plugin (e.g. native client in Chromium).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s