[ecasound] Ecasound.NET

New Message Reply About this list Date view Thread view Subject view Author view Other groups

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:

1. NetECI

NetECI is a slightly modified version of the ECI API that allows
applications to communicate with remote ecasound sessions. The
basic use-case is:

(machine-1) (machine-3)
'NetECI App A' <-- TCP/IP --> 'ecasound -c --daemon'
                                    ^
(machine-2) |
'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
implementation details.

3. Protocol

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
possible, too.

The protocol itself will probably be a request-response system, where the
request format is:

--cut--
<eiam-command> <arg1,...,argN><crlf>
--cut--

... and the response:

--cut--
<return-code> <type> <return-value>
--cut--

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>.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Jun 28 2002 - 02:11:08 EEST