Conceptual/Data Framework

Richard Franks spontificus at gmail.com
Mon Dec 4 17:41:06 CET 2006


I've been thinking a lot more about this idea over the weekend:
http://lists.openmoko.org/pipermail/community/2006-December/000512.html

But it's probably time to present these ideas a bit more
comprehensively to elicit constructive feedback.

Terminology:
transform - takes input, processes, outputs.
data stream - the output to input path

To recap, the purpose is to provide a combined scalable framework for
both the transmission and processing of both data-streams and
arbritrarily abstract concepts. The framework would present a
homogenious interface for all applications, and by passing on
computational load to the framework, applications subscribing to the
same transform could share resources efficiently.

An simple example of a shared set of transforms, might be a voice
recorder which operates at the same time as an incoming call, both
requiring the same level of audio-filtering.

An example of a 'concept' may be 'user availability' (e.g. 0-100) or
'network usage' (0-100). In each conceptual instance, text could
further abstract the pure number - user availability of 0 = "no
contact". 1-10 = "high priority only".

A concept can be constructed from a transform in two ways:
1) Subscribing to 'statistics' of the transform. E.g. subscribing for
a callback every second on an audio transform would keep your
application notified of the higher-level downstream status.
2) From one or more existing concepts or system-states.

I'd say conceptually the system (let's call it
swan - "system without a name", for now) could be broken down into two main
areas:
1) The transform-manager which handles calls/subscription requests -
creates/unloads transforms dynamically as needed. So you have a single
entity which knows the structure of the network at any one time.
2) The transforms/plugins themselves

Since an application never interacts directly with the transforms,
they could reside as shared libraries (e.g. /usr/lib/swan/lib*.so)..
whether the transform is a kernel-module, or a library itself
(undecided - preferences?) the application should just be able to do
something similar to:

#include <swan.h>
...
// Transform Manager as a singleton
//
transformManager *tman = transformManager::Instance();

// Creates a hook into the raw microphone audio device, at a rate of 44k,
// and returns data blocks 1000 milli-seconds long.
//
dataFlow *myDataFlow = tman->subscribe("raw audio input", "rate:44000",
"period:1000");

while ( !mainloopEndCondition ) {
  while (myDataFlow->unprocessedDataBlocks() > 0) {

    // get access to the data
    //
    dataBlock *myDataBlock = myDataFlow()->getNextDataBlock();

    // ... do whatever you want with the data ...
  }
  // other main loop stuff
  ...
}


Now, instead of subscribing to "raw audio input" above, your
application subscribes to "myhomepc:raw audio input", then you've got
the basis for a very powerful application. Except the example above
has no error-checking, but still.

Because all transform-related calls would be directed to the Transform
Manager, the application does not need to worry about how to connect
to other remote machines, that code (Local Transform Manager to Remote
Transform Manager comms) only needs to be written once.

Finally, what is the best way to implement the transforms?

What if each transform allocated a shared memory segment for its
output buffer, and each transform was a self-contained thread? When
the output buffer is full, it could relinquish its share, and pass
ownership onto the next upstream transform or application. It then
allocates a new shared memory output buffer and continues the pattern.

For some data-streams, e.g. video/audio processing.. the buffer size
does not change, only the contents - so by passing on shared memory
segments in a controlled manner, it is possible to avoid expensive
copying.

When a transform has >1 subscriber, only one subscriber could
legitimately write to the same shared memory segment - this could be
handled by the transform-manager.

It would be rather easy to write and redistribute transforms, as the
Framework would be providing all the major hooks and the base classes
to handle the multi-threading/memory segment sharing stuff.

Any thoughts/comments/criticisms/xyz does it already statements, welcome :-)

Cheers,
Richard




More information about the community mailing list