|
From: Steve H. <S.W...@ec...> - 2002-11-06 14:59:00
|
[putting this back on the list] On Wed, Nov 06, 2002 at 02:26:40PM +0000, Phil Kerr wrote: > The biggest difference between DMIDI and MWPP is it's networking scope. > MWPP has been optimised for Internet transmission whereas DMIDI is > optimised for LAN's and is much closer to raw MIDI. The device > identification schema also follows MIDI closer than MWPP which uses > SIP. OK, makes sense. I gues that means we should support both, and probably OSC, as that seems quite popular and has better resultion than MIDI. It is also UDP based IIRC. All incoming event protocols should be normalised in some way IMHO. > You mentioned a service discovery mechanism, do you mean some form of > application introspection that can be broadcast? This is an interesting > area I've been doing some thinking about. Any further thoughts in this > area? Yes, thats it. I've done some work in this area. There are two forms of serveice discovery, syntaic (API level) and semantic (er, harder to define ;) but we probably dont need it). There are some existing standards, eg. WSDL (web sevice description language, http://www.w3.org/TR/wsdl), but they tend to be SOAP (XML-RPC) biased, and are probably overkill for what we need unless you want to describe specific services, eg. an envelope editor. Basicly the deal is you have either a well know broker or broadcast your requirements ("I'm an Akai GUI, protocol v3.4, I want an engine"), and you get back a list of candidates. XML is your friend here. The scheme I would suggest goes something like: Broker fires up Engines reister with Broker (easy if the top level engine is also the Broker) UI starts, queries Broker Broker queries each engine in turn to find out if it can handle the UI Broker retrurns list to UI This also scales to multiple Engines on multiple machines, it just means that the Engine has to register with an external Broker. If the Engines are external, but they hold open a socket to the Broker then they can tell if it sudenly goes away (or vice versa), which helps. - Steve |