[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

testing mcp implementations



>a) has anyone developed any usefull packages specs/implementation they
>could/would like to share on this list? (or is it all top secret right now?)

most of our stuff is wrapped up in private for now, but here's a cord
we did that i think is too dumb to be proprietary.  i am not AT ALL
proposing this as a standard; i just thought it might be interesting
as an example.  if anyone implements a server side version, i'll
polish up our client implementation and we can see if they can talk
too each other.

we didn't actually do the right thing with package names (since at the
time, the spec was still in flux), but i suppose it would be package
dns-com-att-research-twin-audio, cord of the same name.  ("twin" being
a project group, more or less.)

an audio cord is basically a channel through which the server can play
sounds consecutively at the client.  at any given point, it can be
idle or playing a sound; the server can tell it to play a new sound,
interrupting the current sound if there is one, and can also tell it
to stop playing.  multiple sound players may be in existence and
playing at the same time; it's up to the client author to deal with
that.  "sound" is ill-defined, but basically translates to something
found at a URL that you can play somehow.  (we used the
netscape.application.Sound API, which was based on the JDK 1.1 API,
which i think just handled .wav files or something.)

two cord messages, both of them server->client:

  play url: STRING

    retrieve the sound at the given URL and start playing it.  if a
    sound is currently playing, stop it.

  stop

    if a sound is currently playing, stop it.

whee.

--erik