Conceptual/Data Framework

Richard Franks spontificus at
Thu Dec 7 20:34:09 CET 2006

On 12/5/06, Jeff Andros <whitedrought at> wrote:
> On 12/5/06, Richard Franks <spontificus at> wrote:
> > 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.
> >
> yeah, if you want to put it up somewhere I'd like to give you a hand

Awesome! I've been debating over the last few days whether the scope
is valid. On one hand, it would be very nice to stream data from my
home pc, with a simple call such as:

dataFlow *myVideoFlow =
"scale:160x120", "period:~");

However, I can think up many more uses for abstracted concepts, than
data-streams and there are many more applications which would derive
immediate benefit from a unified source for concepts than

Say you want to do a little post-processing upon the GPS location, to
take account of velocity and acceleration vectors to produce a
prediction of location +5 seconds:

dataFlow *myGPSFlow = transformManager->subscribe("projected GPS
location", "delta:5s");

Is that an abstracted concept, or a data-stream?
  dataBlock *myGPSDataBlock = myGPSFlow()->getNextDataBlock();
  float lat = myGPSDataBlock->getValue("lat");

vs the video example earlier:
  dataBlock *myVideoDataBlock = myVideoFlow->getNextDataBlock();
  char *myVideoFrame = myVideoDataBlock->getValue("frame buffer");
  uint32 frameSize = myVideoDataBlock->getValue("frame buffer size");

or availability:
  dataFlow *myAvailabilityFlow =
  dataBlock *myAvailabilityDataBlock = myAvailabilityFlow->getNextDataBlock();
  uint8 myAvailabilityNumber =
MyAvailabilityDataBlock->getValue("numeric availability");
  char *myAvailabilityText =
MyAvailabilityDataBlock->getValue("textual availability");

My point is that conceptual states and conventional data-steams have
many similarities, indeed, the distinction can only be made by the
application which subscribes to it.

However, time-sensitive data-streams - such as audio processing are
going to be tough to handle because they need to have very small
data-blocks to 'simulate' asynchronous processing.. which is where
questions of efficiency start to raise their head with the increased
context switching.

So, I'm considering leveraging from the API similarities for concepts
and data-streams, by focusing on tuning the transformManager for
concepts only -- this means that, if required, low-latency data-stream
support could be integrated fully into the transformManager at a later
date, but the initial release would not be overly cumbersome and would
perform one task fantastically, rather than both tasks less

In that case, a data-stream transform could be written to perform any
task anyway.. but the system would not be optimised for low-latency
high-bandwidth streams initially.

What do you think?


More information about the community mailing list