Subject: Re: [linux-audio-dev] LCP v0.1.0
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Mon Dec 10 2001 - 21:55:15 EET
On Mon, Dec 10, 2001 at 01:57:30 +0100, Richard Guenther wrote:
>
> For no param change rate this cost will be greater than the communication
> cost involved anyway.
Welll... cost is a bit of a vague term. HTTP has both higher latency
(slightly), computational cost (greatly), complexity (massivly).
You could argue in favour of an HTTP implementation that wasn't propper
HTTP, but then where's the point?
My view of some protocols, in order of roughly how appropriate I think
they are for this problem:
LCP:
+ fast
+ simple
+ we allready have exemplar code
- not an existing standard (does that matter?)
XMLP (SOAP):
+ standard
+ you could use WSDL too
+ buzzword compliant
- lots of float<->string conversions
- needs XML parser
- both frontend and host need to run servers
- complex
CORBA:
+ standard
- *very* big and complex
- need an ORB
- both frontend and host need to run servers
OSC:
+ standard (for small values of standard)
+ media centric
- horrible (ok, its subjective, but not /that/ subjective!)
- complicated (less complicated than HTTP though)
RPC:
- its RPC!
HTTP:
+ standard
+ lots of clients (I don't think this helps much, but...)
- not media centric
- complicated
- 99% of it is redundant
- slow
- lots of float<->string conversions
- both frontend and host need to run servers
MIDI:
+ standard
+ media centric
- inapropriate (its only really meant for sending 7/14bit ints over low
bandwidth serial)
- awkward (would require wrapping floats in sysex)
- wouldn't be compatible with anything else anyway
This archive was generated by hypermail 2b28 : Mon Dec 10 2001 - 21:50:13 EET