Subject: [ecasound] Ecasound.NET
From: Kai Vehmanen (k_AT_eca.cx)
Date: Fri Jun 28 2002 - 02:10:47 EEST
Ok, not really. :) But I do intend to use the 'net'.. I mean why waste
perfectly good marketing money! :)
I've continued developing the 'shared access to ecasound sessions'
concept. After considering a few different implementation approaches, I've
come to the conclusion that extending the ECI API is by far the
easiest and most flexible solution. Here's a short summary:
NetECI is a slightly modified version of the ECI API that allows
applications to communicate with remote ecasound sessions. The
basic use-case is:
'NetECI App A' <-- TCP/IP --> 'ecasound -c --daemon'
'NetECI App B' <-- TCP/IP ---------|
2. ECI vs NetECI
The only required API change is extending the init function. So instead of
'eci_init(void)' you'd have 'neteci_init(const char* hostname, int port)'.
The NetECI library will handle all the network communication. App using
NetECI can just issue EIAM commands as usual and not worry about the
NetECI is really just a RPC-version (remote procedure call, or
remote-invocation (RMI) for you java-men) of ECI. I could use any of the
numerous available RPC mechanisms (Sun's RPC, CORBA, SOAP, KDE's DCOP,
GNOME's Bonobo, XML-RPC, etc, etc) for the implementation, but I'm pretty
certain won't. Instead the protocol will be a straightforward, text-based
protocol using TCP/IP or UNIX-sockets. I can once again reuse the EIAM
parser code in libecasound and use it this time as a protocol parser. This
way there's really not that much new code for me to write.
One interesting thing is that it will be quite easy to write a native
implementation of the NetECI client side in perl, python, C, java, etc.
You just need to handle the TCP/IP communication with the ecasound daemon
and that's it, no need to link against libecasound or install glue-code
like pyeca. Of course, using the C++ NetECI implementation would still be
The protocol itself will probably be a request-response system, where the
request format is:
... and the response:
<return-code> <type> <return-value>
So extremely simple. One possible problem is bandwidth usage, so I don't
want to make the protocol overly complex. Any comments?
-- http://www.eca.cx Audio software for Linux!
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Fri Jun 28 2002 - 02:11:08 EEST