Hi all! 2011/7/23 David Baelde <[email protected]>: > On Wed, Jul 20, 2011 at 6:10 PM, Romain Beauxis <[email protected]> wrote: >> A question relative to this that maybe people here can help us >> answering is the following: >> What would be a nice protocol/API for machine-oriented >> communications between liquidsoap and external applications? > > I agree with the answers that have been given, JSON in particular > sounds good since it is widespread, simple and we already have > preliminary support. However, in my opinion, before making the server > interface more standardized, we need to integrate it into the > scripting language. This is necessary to avoid stupid things like the > duplication of insert_metadata and server.insert_metadata, as well as > the annoying server.execute() calls, etc. Moreover, once the server is > just a way to execute scripted functions, it'll be very easy to adapt > it to various formats. > > I won't start this right now but it's high on my TODO list...
I've had some thinkings about this topic lately, here is what I came up to. Some of the ideas below were already proposed by David. Protocol ====== I think the protocol that seems the most interesting to me is JSON-RPC, described in its 2.0 version there: http://groups.google.com/group/json-rpc/web/json-rpc-2-0 It seems simple enough and should be standard enough to make it easy to use for users. Concerning xml vs. json, I personally prefer JSON because I find this format less bloated and more readable. Interface ====== Our ultimate goal is to export everything that we used to do through telnet using json-rpc. The nice idea would be to have a command such as: rpc.register(function) which would use the function's type to deduce which type of json-rpc request corresponds to it. For instance, a function "foo" of type: (int,float) -> int would translate into a request of the form: { method: "foo", params: { unamed: [1, 3.14]} , ... } Named arguments could also be taken into account. If the type is: (bar:int, int) -> int then the json-rpc request would be: { method: "foo", params: { bar: 1, unamed: [3] }, ...} The rules for translating liq's types to json back and forth could be generalized from the current json_of. For instance, a function of type: (metadata) -> unit would give: { method: "foo", params: { unamed: [ { title: "foobar", artist: "kikoolol" } ] } The same goes for the type of response sent by the function: a function returning variable x would lead to a json-rpc response built using json_of(x).. This could be also adapted to telnet. For instance, insert_metadata would translate in telnet as: insert_metadata title="foobar",artist="kikoolol" Getting rid of the current mess ====================== The bigger problem currently is the mess we have in the functions that are exported to telnet when creating a source and those that exported through server.register in the scripting language. This creates situations such as rms vs. server.rms etc.. This problem is due to the fact that historically, we did not intend to let users register telnet commands. However, this feature is now widely used and is tremendously useful. Thus, we have been slowly moving functionalities out of pure telnet and making them accessible through the scripting language. This was the case with insert_metadata in the latest release. However, this approach is very limited for two reasons: * Some functionalities are intrinsic to some specific sources, for instance the queues in a request source * The current approach is ugly and ad-hoc: insert_metadata(source) returns a new source and a function to insert metadata. This is cumbersome, bloat the type of the function and is just not very elegant.. The idea proposed by david some time ago was to lift the liquidsoap language and add some object-oriented aspects. I think this is really a good idea! For instance, instead of writing: s = source.on_metadata(f, s) one would write: s.on_metadata(f) Similarly: x = insert_metadata(s) insert_function = fst(x) s = snd(x) would be written: insert_function = s.insert_metadata (or even simplier..) In other words, a lot of functions applying to sources could be exposed as methods attached to sources. This would simplify a lot. Concerning optional functionalities, such as queues in request sources, I am not sure yet. I think it could be a optional methods, which would return None (or null or anything else) if they do not exist.. Of course, these are huge changes in the language. They raise many questions, such as whether we should type the source objects with their methods or let them be typed "source" as before etc.. However, I think this would be the proper solution to finally move everything out of telnet and expose telnet-specific functions inside liquidsoap scripts. Conclusion ======== 1) We need a better API for process-to-process communications. JSON-RPC seems a nice choice for its simplicity and its natural integration in many existing frameworks. 2) We should export functions through json-rpc using their type in order to implicitly find and export their expected request and response. 3) In order to expose telnet-only functionalities in the scripts, we could look at attaching methods to sources in a object-oriented fashion. Timeline and implementation ===================== My concern here is that, although all these ideas are really exciting, we are currently supposed to be preparing a stable release. It seems to me that all those ideas would take way too much code and changes right now and would postpone even further later a stable release. Therefore , I think we should unfortunately hold our horses on this, think about it a lot, and do it immediately after we have a 1.0 stable release. Please, do comment. Once we have a sort of agreement, I'll open some tickets and sub-tasks in the bug tracker so that we can keep track of the discussion :) Romain ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
