How would a blocking call be created? How would you implement this in a way that wouldn't lock one machine to another machine's performance. For quite some time now, RPC has been considered a very bad idea since it mixes reliable and unreliable semantics.
With a network you're never actually sure that a message will arrive (see the messenger problem). And yet one expects procedure calls to be reliable. So what happens when you make a RPC call, and then the remote server dies? What are the semantics on the sender side? Secondly, RPC kind of flies in the face of Clojure in general. Sending procedure calls? Why not send data? I've been thinking about this a lot recently, and how the entire process can be made to be lock safe. That is, when a remote server dies, the system continues to respond as normal (see Joe Armstrong's thesis). I'm not completely convinced that the CSP style works well in this context, and that instead we should perhaps model these systems after unreliable message passing, as that's really all that you are promised by the network protocol anyways. Timothy Baldridge On Thu, Aug 1, 2013 at 9:32 AM, <toberepla...@gmail.com> wrote: > With core.async, cljzmq <https://github.com/zeromq/cljzmq>, and now > zmq-async <https://github.com/lynaghk/zmq-async>, there's an opportunity > to link RPC to channels and be free of the underlying transport system. > I'm proposing an RPC library that sends and receives data over channels. > > The idea is to have a two-way communication context as a map with a > send-channel, receive-channel, serializer, and deserializer. The user > would be responsible for the transport mechanism between the "client" and > the "server". > > When a user makes a request, the library would create a map to follow the > JSON-RPC <http://www.jsonrpc.org/specification> and attach a UUID to it > then send it down the send-channel. This UUID could be used in conjunction > with pulling items off of the receive-channel to handle responses. > > The data flow would be: > user-request -> wrap-in-specification -> client-serializer -> > client-send-channel -> transport-provider -> server deserializer -> > server-receive-channel -> user-function -> server-serializer -> > server-send-channel -> transport-provider -> client-deserializer -> > unwrap-specification -> client-receive-channel -> user-response-handling. > > The library would be responsible for wrapping the requests and responses > according to the specification, but not the serialization mechanism nor the > transport, since those could be very different depending on the problem. > Utilities could be provided for a "blocking call" and managing cycling > through responses on the receive-channel in order to find a specific > response that has not yet been processed. > > As an example, the above workflow should be able to work seamlessly with > the channels provided by zmq-async. The send-channels provided would be > used as is, and the receive-channels would be used with an additional > channel outside of it to take the responses off and deserialize them before > returning to the user. The transport provider, of course, would be ZeroMQ. > > Are there any projects already doing this? Would people be interested? > Any feedback? > > -ToBeReplaced > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
