architecture/platform and language discussion

[dirkleas]

two level conversation: 1) architecture/platform, and 2) implementation language

I could implement this (extremes to clarify options) as either a client tool running on your rack machine, or a cloud-based service with a friendly web front end and support for REST/gRPC access. a web front end will exist for collaborative features no matter how the core features get implemented, but was assuming client-side binary for performance as I'll personally be using this CLI while patching/wiggling

I was planning on a client implementation for performance and the assumption that one isn't connected to the internet during all rack sessions, but am interested in your input. I'll put a for any cloud bits up through aws lambda and persistence via dynamodb for speed/scale/performance/PRICE

also, was leaning towards implementing most of the code in golang as it's robust, [cross-]compiles to dependency-free binary, and has trivial support for concurrency -- also flexible -- considered python and node.js/javascript. python + jupyter notebooks are epic for magic of all sorts, but requires installing some requisite plumbing (free and easy for all three rack supported platforms)

remember, rack is written in c++, and there's no introspection (yet, fingers crossed), so there'll still be a requisite c++ shim/component able to instantiate a given/each plugin/module and tease out the metadata as json

looking forward to your input, use cases, etc.

[zeronoises]

As Rack becomes more stable it will be increasingly used in live situations - often in places without a guaranteed connection to the net...