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 <[EMAIL PROTECTED]> 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
_______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
