ZeroMQ

Initial Design Cut: The API

Here’s the way I see the first design. FileMQ has to be distributed, so every node can be a server and a client at the same time. But I don’t want the protocol to be symmetrical, because that seems forced. We have a natural flow of files from point A to point B, where A is the “server” and B is the “client.” If files flow back the other way, we have two flows. FileMQ is not yet a directory synchronization protocol, but we’ll bring it quite close.

Thus, I’m going to build FileMQ as two pieces: a client and a server. Then, I’ll put these together in a main application (the “filemq” tool) that can act both as client and server. The two pieces will look quite similar to the nom_server, with the same kind of API:

fmq_server_t *server = fmq_server_new ();
fmq_server_bind (server, "tcp://*:5670");
fmq_server_publish (server, "/home/ph/filemq/share", "/public");
fmq_server_publish (server, "/home/ph/photos/stream", "/photostream");

fmq_client_t *client = fmq_client_new ();
fmq_client_connect (client, "tcp://pieter.filemq.org:5670");
fmq_client_subscribe (server, "/public/", "/home/ph/filemq/share");
fmq_client_subscribe (server, "/photostream/", "/home/ph/photos/stream");

while (!zctx_interrupted)
    sleep (1);

fmq_server_destroy (&server);
fmq_client_destroy (&client);

If we wrap this C API in other languages, we can easily script FileMQ, embed it applications, port it to smartphones, and so on.