4 Aug
2004
4 Aug
'04
3:49 p.m.
Hi,
One of the things that I came away from the meeting in Germany with was
a sense that the LASH protocol used for client<->server communication
needed to be better defined, both on the wire and in the api. What is
really necessary is a network protocol and api designed to allow
high-level ideas like sessions to be represented in a simple format.
The properties that I had been working on have become gobjects and what
was to be a new networking system is a seperate, gobject-based library
to provide a high-level networking api (eg, session_scan(),
session_join(), etc)
The TLA OSC has been banded about quite a bit, and this is not out of
the question; it would be in a set of usable lower-level protocols (or
perhaps the set :)
Bob
--
Bob Ham <rah(a)bash.sh>
/-\
\ / Gay Whales
X Against Racism
/ \
4 Aug
4 Aug
4:20 p.m.
New subject: [linux-audio-dev] Re: [ladcca] lash directions
On Wed, Aug 04, 2004 at 06:34:32 +0100, Bob Ham wrote:
The properties that I had been working on have become
gobjects and what
was to be a new networking system is a seperate, gobject-based library
to provide a high-level networking api (eg, session_scan(),
session_join(), etc)
The TLA OSC has been banded about quite a bit, and this is not out of
the question; it would be in a set of usable lower-level protocols (or
perhaps the set :)
OSC is pretty neat, however it has a few features that make it not ideal
for LASH:
* theres no return codes or anything - if you want a reply you have to
receive an explict, seperate reply packet.
* most clients only use the UDP transport, so theres no guantee that the
server got your messge. This is not really a big deal - in reality UDP
is quite relaible, and you could require the TCP transport, and still be
in the letter of the spec.
Despite this, I think OSC might be a good choice. The obvious alternatives
(CORBA, SOAP, XML-RPC, etc.) are all really heavyweight. An alternative
might be D-BUS, but its paint is a little wet, and its not network
transparent.
Incase you dont know, a typical OSC message might look like (but in binary
form):
/lash/do/something is 1 "my session"
[method path] [types] [arguments]
The types can be things like string, integer, float, double, binary blob,
timestamp etc. They are integer+string in the example.
- Steve
4:48 p.m.
New subject: [linux-audio-dev] Re: [ladcca] lash directions
On Wednesday 04 August 2004 20.05, Steve Harris wrote:
On Wed, Aug 04, 2004 at 06:34:32 +0100, Bob Ham
wrote:
Just throwing out ideas...
What about this D-BUS thingy that seem to have a very good chance of becoming
a widespread desktop ipc standard (with netwprk support)?
It seems the next versions of both KDE and GNOME will utilize it atleast.
/R
--
http://spamatica.se/music/
The properties that I had been working on have
become gobjects and what
was to be a new networking system is a seperate, gobject-based library
to provide a high-level networking api (eg, session_scan(),
session_join(), etc)
The TLA OSC has been banded about quite a bit, and this is not out of
the question; it would be in a set of usable lower-level protocols (or
perhaps the set :)
OSC is pretty neat, however it has a few features that make it not ideal
for LASH: 
6:04 p.m.
New subject: [linux-audio-dev] Re: [ladcca] lash directions
On Wednesday 04 August 2004 02:05 pm, Steve Harris wrote:
On Wed, Aug 04, 2004 at 06:34:32 +0100, Bob Ham
wrote:
What do you think about shoehorning audio streams into OSC?
The properties that I had been working on have
become gobjects and what
was to be a new networking system is a seperate, gobject-based library
to provide a high-level networking api (eg, session_scan(),
session_join(), etc)
The TLA OSC has been banded about quite a bit, and this is not out of
the question; it would be in a set of usable lower-level protocols (or
perhaps the set :)
OSC is pretty neat, however it has a few features that make it not ideal
for LASH:
* theres no return codes or anything - if you want a reply you have to
receive an explict, seperate reply packet.
* most clients only use the UDP transport, so theres no guantee that the
server got your messge. This is not really a big deal - in reality UDP
is quite relaible, and you could require the TCP transport, and still be
in the letter of the spec.
Despite this, I think OSC might be a good choice. The obvious alternatives
(CORBA, SOAP, XML-RPC, etc.) are all really heavyweight. An alternative
might be D-BUS, but its paint is a little wet, and its not network
transparent.
Incase you dont know, a typical OSC message might look
like (but in binary
form):
/lash/do/something is 1 "my session"
[method path] [types] [arguments]
The types can be things like string, integer, float, double, binary blob,
timestamp etc. They are integer+string in the example.
- Steve
8:20 p.m.
New subject: [linux-audio-dev] Re: [ladcca] lash directions
On Wed, Aug 04, 2004 at 03:47:39 -0400, John Check wrote:
I wouldn't, its not designed for streaming, use RTP or similar.
- Steve
Despite this,
I think OSC might be a good choice. The obvious alternatives
(CORBA, SOAP, XML-RPC, etc.) are all really heavyweight. An alternative
might be D-BUS, but its paint is a little wet, and its not network
transparent.
What do you think about shoehorning audio streams into OSC? 
7:46 p.m.
New subject: [linux-audio-dev] Re: [ladcca] lash directions
On Wed, 2004-08-04 at 14:05, Steve Harris wrote:
On Wed, Aug 04, 2004 at 06:34:32 +0100, Bob Ham
wrote:
At the risk of sounding like a broken record, I vote OSC as well.
LASH is for Controlling Sound applications after all.. :)
The lack of return is annoying, but not all that tough to work around.
-DR-
The properties that I had been working on have
become gobjects and what
was to be a new networking system is a seperate, gobject-based library
to provide a high-level networking api (eg, session_scan(),
session_join(), etc)
The TLA OSC has been banded about quite a bit, and this is not out of
the question; it would be in a set of usable lower-level protocols (or
perhaps the set :)
OSC is pretty neat, however it has a few features that make it not ideal
for LASH:
* theres no return codes or anything - if you want a reply you have to
receive an explict, seperate reply packet.
* most clients only use the UDP transport, so theres no guantee that the
server got your messge. This is not really a big deal - in reality UDP
is quite relaible, and you could require the TCP transport, and still be
in the letter of the spec.
Despite this, I think OSC might be a good choice. The obvious alternatives
(CORBA, SOAP, XML-RPC, etc.) are all really heavyweight. An alternative
might be D-BUS, but its paint is a little wet, and its not network
transparent.
7449
days inactive
7449
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
5 participants
participants (5)
-
Bob Ham -
Dave Robillard -
John Check -
Robert Jonsson -
Steve Harris