build an app server?

[Brian Warner]

I've been thinking it might be handy to build a sort of "application server", using Foolscap as the transport. Something like my limited understanding of the Waterken server.

Foolscap demonspawner: run multiple services from a single tub, kind of like the waterken server. Once the tub is running, use 'tool add' to allocate a swissnum, create a directory (with a hash of the swiss), populate it with a skeleton .rpy, then print the furl. The rpy should define a Service+Referenceable that will be started the first time someone hits the furl. Think Waterken for foolscap. Also, once remote promises are in, a CLI tool that evals "p.foo(12).bar(34)" and prints the result would be handy.

This could be a superset of the current file-transfer and command-runner demos in the docs/ directory. Maybe something like:

flappserver create DIR
flappserver start DIR
flappserver add shell 'ls /home/public'   -> FURL
flappserver add file-upload /home/inbox   -> FURL

where the 'shell' and 'file-upload' words are keys that map to some piece of code. The 'flappserver add' command would create a file in its swissnums/ directory, filled with python code that instantiates an object to do the desired operation.

[Brian Warner]

Other libraries which use foolscap could provide plugins, that would add new things to the list that "flappserver add" knows how to make.

[Brian Warner]

[c9937f0adac5764fd1c4e225189c2d385ab581bc] starts work on this.

Hm, it might also be useful to create a generic "flappclient", with plugins that let you do "flappclient file-upload ..." and "flappclient exec". So far I've only been thinking of dedicated commands (like upload-file and exec-command), but for services which are meant to be accessed by a command-line tool, a generic flappclient seems more convenient (users which run a specific command a lot could always write a little shell-script wrapper to avoid typing "flappclient" all the time).

Next step is to write tests, implement the actual services, and write the clients.

[Brian Warner]

[41ab3f84d851cc2b4f6f73226fc2f2ff67e65659] adds the last pieces to what I want out of the app-server. It still needs to have a plugin mechanism, but the CLI feels pretty good, and the implementation works fine (and there's good-enough unit test coverage too). Time to close this one.