Light sensor

[Richard Franks]

On 11/30/06, Tim Newsom <cephdon at gmail.com> wrote:
> > the problem with doing it this way, is you'd need some way to notify
> > each application of all the sensors available at runtime, or you
> > re-compile each availability sensitive app for every combination of
> > sensors (having that many versions of software is sure to turn off
> > Sean's dad) there's definately more to think about on this one
>
> Are you thinking of not only notifying each application on the number of
> sensors.. (That would be easy enough in the api) but also to let them
> have access to the setup/configure api for each one?

Yes - each transform (raw audio, touch screen state, last user
activity time, user availabity,etc) can decide on its own how to
handle subscription requests -- e.g. for when >1 application makes a
request to the same datasource.

Also, another bonus is that you don't need to recompile anything
whenever the transform-network changes - it would change quite often.

When a transform handles its last 'unsubscription', it could unload
itself -- this way resources are saved, and the dead branches of the
network are pruned. When an application tries to subscribe to that
transform next time, the transform-factory which handles the request
can instantiate it - that way you have:
1) User opens 'voice recorder'
2) Application loads, and request is made for (filtered audio:44k)
3) transform-manager creates (filtered audio) with given parameters
4) (filtered audio) makes a request for (raw audio:44k)
5) transform-manager creates (raw audio) with given parameters -
direct hardware interface
6) Another Application makes a request for (raw audio:22k)
7) Transform-manager passes request onto existing (raw audio) with parameters
8) The (raw audio) interface can be written to multiplex its output to
both Applications or create another instance of (raw audio) with the
22k parameter


> Enumerating over each sensor that is active would be fairly easy using
> the plugin mechanism previously described...  If every plugin had the
> same output ranges... Say 0 to 255 or whatever and using the probability
> scenario he talked about the application would only need to know one
> interface, I.e. Availability.   As I understand the proposal, and I
> might be wrong, it would end up a heirarchy.  Lower level plugins could
> be accessed at any level but the common usage would be to build
> behaviors going up from the sensors and applications would interface
> with that... Is that right?

Yup - and because >1 application can share the same logical
processing, you save CPU cycles too.


> With that in mind, each plugin would register with some service which
> handles the interface to applications.  Each behavior created would do
> the same and gain access to the sensors available.  Then a control panel
> could be created to enable/disable some but not all plugins at the will
> of the user, though that would modify the behaviors, they would then act
> on the information currently available.

The flexibility and security of the network both become especially
crucial when you start referencing external nodes:

homepc:(user availability)
bobsneo:(user availability)
tomsneo:(microphone audio)

Upon a subscription to the last one, a dialog would be displayed upon
Toms neo1973 asking whether he accepted that level of security access.
It would then appear in that control panel if it was a brand new
connection.

The higher-risk security vulnerabilities should be a compile-out
option for the cautious ;-)

Although, that would make it very simple to write a little program to
make a walkie-talkie over GPRS.


> Seems like a fairly interesting concept.  Do I understand the concepts
> or am I missing something?

I think you did a better job than me of describing the idea :-)

Richard