Consider alternative server format

[daveyarwood]

An HTTP server might not be the most practical thing. It might be worth pursuing something more lightweight and/or lower-latency.

Other ideas:

• ZeroMQ
• Redis
• Clojure 1.8 Socket Server REPL

[daveyarwood]

I'm learning more about ZeroMQ and it's totally awesome. A big plus is that there is a pure-Java implementation, which means we can switch to ZeroMQ without requiring users to install any native dependencies, and it's compatible with native ZeroMQ, which is great if we ever want to swap out Alda components with better, non-JVM versions.

The ZeroMQ documentation is also fantastic. I see a couple of patterns already that we can use to make the Alda system more robust. I have some ideas that I think could help with #243 , but that's out of scope for the moment.

For now, I am working on replacing the Alda client/server relationship with a simple ZeroMQ REQ/REP socket. From the perspective of the Alda client, it should work exactly the same, but I think the server will have much lower overhead and be more performant.

[jimcheetham]

0MQ is awesome :-) I haven't thought about this before, but it would be interesting to expose the server directly to other people's implementations of clients, and for it to be very predictable time-wise. That way we could have a bunch of different "clients" submitting their notes independently ... and for the output to be combined (and capable of being captured as a score). Then a midi-to-alda client could capture real instrument playing, pass the result to the server, and the server emits a score that can be cleaned up by an editor later ... -jim

On Sun, Aug 14, 2016 at 7:22 AM, Dave Yarwood notifications@github.com wrote:

I'm learning more about ZeroMQ and it's totally awesome. A big plus is that there is a pure-Java implementation https://github.com/zeromq/jeromq, which means we can switch to ZeroMQ without requiring users to install any native dependencies, and it's compatible with native ZeroMQ, which is great if we ever want to swap out Alda components with better, non-JVM versions.

The ZeroMQ documentation http://zguide.zeromq.org is also fantastic. I see a couple of patterns already that we can use to make the Alda system more robust. I have some ideas, but that's out of scope for this issue.

For now, I am working on replacing the Alda client/server relationship with a simple ZeroMQ REQ/REP socket. From the perspective of the Alda client, it should work exactly the same, but I think the server will have much lower overhead and be more performant.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alda-lang/alda/issues/175#issuecomment-239637234, or mute the thread https://github.com/notifications/unsubscribe-auth/AAd7i2cuXNR_Ts_v7CLWdLqW2q255409ks5qfhmSgaJpZM4HJMXz .

[daveyarwood]

That's a great idea! I think we already have that functionality, at least to some degree, in that an Alda server can handle multiple clients (even from different hosts), and if the client uses the -a/--append option, then the code he/she submits will be appended to the current score in progress.

I actually played around with this at work one day -- I ran an Alda server on my machine, and told my coworkers they could run something like:

curl -X POST (my.ip.address):27713/play/append -d 'bagpipes: c1~1~1~1~1'

Then I left the server running, and endured all kinds of madness coming out of my speakers as my coworkers and I collaboratively wrote a completely nonsensical Alda score. Afterward, I used alda save -f somefile.alda and looked at the file -- each line of the file was the result of a separate call to my server to play a string of Alda code.

I'm definitely very interested in allowing people to explore swapping out different pieces of Alda with their own implementations written in Language X. (If they're especially good, I may even entertain the idea of replacing some of the Clojure pieces we've got!) For more thoughts on that, see #186 . Of course, people can also explore alternate interfaces -- a midi-to-alda client sounds intriguing.

So what I'm playing with right now is replacing the HTTP server with a ZeroMQ socket that listens for JSON messages that look something like this:

{
  "command": "play",
  "body": "piano: c8 d e f g a b > c",
  "options": {
    "append": true
  }
}

and then takes the appropriate action. (If we really want to optimize for performance, we could use binary JSON or something, but so far, even just with sending long strings of JSON, it feels super fast already!)

So if someone wanted to implement their own client, they would only need to write a program that can connect to a ZeroMQ REQ/RES socket on tcp://*:27713 (or whatever host and port the Alda server is running on) and send a string of JSON containing the appropriate command and options.

[daveyarwood]

1.0.0-rc32 is out, featuring a rewrite of the server/client relationship as a ZeroMQ REQ/RES socket!