Subject: Re: [ecasound] NetECI and stanadlone ECI impls; edi-27 and edi-28
From: Kai Vehmanen (k_AT_eca.cx)
Date: Tue Oct 01 2002 - 04:48:11 EEST
On Sun, 29 Sep 2002, Tony Leake wrote:
>> Anyone interested in writing a standalone C/python/perl/php/tcl ECI
>> implementation? Part of the job should be quite straightforward, but
> I'll have a go at writing the php implementation as I really like this idea.
[...]
> Are you looking for these to be built before you work on the new ecasound
> code to get ideas for the return values parsing, and doing the forking from
> within php/perl/etc?
Actually the required changes are not that big, so I'd like to do them
quite soon. I've already written some code for a standalone C
implementation. Simultanous work on other implementations would help
in verifying the design.
One of the best alternatives I've come up with so far is reusing the
NetECI protocol wire format:
--- [1. int-output-eci]There would be a new ecasound command for enabling a parser-friendly output mode (for instance 'int-output-eci').
--- [2. well-formed stdout messages]
Once 'int-output-eci' is issued, all output from libecasound to stdout will adhere to the following format:
"<loglevel> <msg-size><crlf><msg><crlf><crlf>"
Different types of messages already all have a different loglevel associacated with them. For instance when setting ecasound's debug level (with -d:x), you're actually setting a mask specifying which loglevels to pass through.
Example: "16 10\r\nMy message". Ie. "My message" (length=10) was sent with loglevel 16.
--- [3. the ECI loglevel]
One loglevel would be allocated to command return values. These messages would adhere to the following format, which is an extension of the message format in the NetECI protocol:
"<ECI-loglevel> <status-code> <return-type> <msg-size><crlf><msg><crlf><crlf>"
Example (response to 'c-selected'): "64 100 s 7\r\ndefault\r\n\r\n". Ie. the response was "default" (length=7), response type s=string, status 100=ok and it was sent with loglevel 64.
...
With this new output mode, it should be quite easy to reliably parse ecasound's output. Just issue a command and then read log messages until you encounter the next message with eci-loglevel. The msg 'status-code' will indicate whether the command succeeded or not. 'return-type' and 'msg-size' will help in parsing the actual message contents (and to find the next well-formed message).
In addition to making parsing easier, the line-feeds (crlf) also serve as a mechanism to recover from errors (parser receives an invalid message and does not know where the next message starts ==> search for an empty line to find a possible new well-formed message).
Comments...?
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Tue Oct 01 2002 - 04:47:07 EEST