@vfrank66 thanks for the contribution and for all your recent PRs. Couple of thoughts:

• I'd love for us not to write user uploaded files to the server's host filesystem. This expands the vulnerability surface a bit, and also means we might need to think a little harder about cross-user sessions if this server is deployed in a cross-user environment. (edit: it's certainly worth thinking about other collaborative use cases, cross-user environments, etc long term).
  • Can we just cache the libraries on the client side and send them along with the standard execution request? We can store in localstorage if needed. This will also simplify the server side code a bit.

What do you think? cc: @evan-gordon

@suyashkumar you called this the server's host filesystem, is this something that is deployed as a non-playground website? I thought this was just a debug playground. In the docs it stats not to be run in production so I assumed it was for debugging the code locally.

I wanted to add this feature for playing with more than 1 shared libraries locally, it is easier than stopping and starting the cql playground because live reloading is not setup. Live reloading I think would requrie another go package which I did think was a good ideal because the playground UI is not but this is really cql engine.

@vfrank66 yeah totally this should be mostly used for non-production use cases as it sits today! I'd love to get this cooking with webassembly and just run everything in the browser in the future, and/or generally have a hosted playground for folks. My thinking in my comment above was if we can do this without saving files on the server side, why not give that a go? It makes the server side much simpler, and the client side is fairly straightforward too. Here's a working example with a demo video: #112 . I'd personally prefer this approach since it's stateless on the server side, simpler on the server side, and still solves the problem of allowing multiple libraries. What do you think?

@suyashkumar I see did not like my PR I think your #112 is betteer, I am happy to close this if #112 is going to make it in.

Right now I am personally not very interested in supporting webassembly, I am interesting in seeing this cql engine move from experimental to beta.