[Simca-developers] the API levels and v2_jam structure

[Artyom B. <ar...@z2...>]

hi 

the following is a result of my evaluation of possibilities to use CORBA
for implementing v2_jam's distributed processing and control
functionality.

CORBA is a bunch of standarts on distributed object systems. it
describes how to create objects that can be accessible to other programs
on the same or remote hosts. i find it handier then proposed earlier
XML over HTTP way to communicate with client(s) + it allows uniformity
of communication (but server-server and client-server will use the same
mechanism).

since CORBA is all that general it's implementations aren't optimized
for media streams. hence the actual media/control streams, which need
realtime performance, shouldn't go via CORBA but rather via dedicated
channels (such as conventional video/audio streams, OSC for control
signals, etc).

1. v2jam APIs

- libv2jam: comon to client and server functionality (e.g. finding the
  CORBA name service) used by libjamka/libsimca
- libjamka: client API - finding the simca-server etc. this library
  allows creating clients.
- simca corba interfaces. i've come up with two interfaces so far -
  SimcaObject and SimcaContainer. simca-server itself implements
  SimcaContainer interface. container allows instantiating the objects
  and moving them from one container to another. object allows its
  properties to be get/set and commands to be executed. these interfaces
  are used by client to control the server(s) and by server(s) to
  interoperate (e.g. create the distributed links).
- libsimca: the objects API, like it is now. isn't CORBA aware. probably
  in the future some of the functions will seize to exist, because will
  be implemented by the simca-server. for now corba interfaces can
  simply wrap around the corresponding libsimca functions.

2. v2jam applications
- simca (or simca-server): implements simca corba interfaces wrapping
  them around the libsimca objects and objects provided by modules.
- simca modules: provide libsimca based objects that perform actual
  media processing.
- jamka: generic v2_jam GUI - connects to simca-servers and allows
  creation of pipelines, starting/stoping them, controlling the objects
  parameters etc.
- other clients: e.g. project specific GUIs, non-GUI controllers:
  scripts, daemons etc. any application linked against libjamka can be
  v2_jam client.

3. plan of implementation
- review the libsimca code and design the simca corba interfaces
- implement corba interfaces / simca-server + finish the libsimca TODOs
  and FIXMEs
- start working on media objects
- design and implement:
  - libjamka (client API)
  - distributed connectivity mechanism
  - simple client (e.g. command line / python based) for testing
    purposes
  - jamka (generic client)

some design things can happen simultaneously, e.g. generic client design
can start now, even though no underlying functionality is here. we'd
rather design libjamka based on jamka description...  i'd like madris
and lenno to think about that, next monday we can meet and discuss
jamka.

cheers,
artm

-- 
Artem Baguinski: <ar...@v2...> <http://www.artm.org/>
V2_lab: <http://lab.v2.nl/> <http://www.v2.nl/>