Conceptual/Data Framework

[Richard Franks]

I started coding this beast last night. Not much to see, but if it
garners any interest I'll chuck up on Sourceforge. There are still
plenty of things to be decided, so if you'd like to contribute code or
ideas, please do :-)

Cheers,
Richard

P.S. Rereading that first sentence makes me think that "Beast" is a
better name than not having a name, but it's all open.


On 12/4/06, Richard Franks <spontificus at gmail.com> wrote:
> 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
>