RE: [Embedlets-dev] Event versus State-driven systems

[Christopher S. <cs...@oo...>]

> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> I think Chris said (or was it Ted):
Chris
>
> > Your point is accepted. I was digressing to a more general discussion of
> > event vs state driven systems because I have run into some
> issues on this
> > front.
>
> Turing's Law would imply that all applications are both state and
> event based
> at some level.  I see no clash between these two.  In fact, I
> would suggest that
> applications need both to function. However, some people do not
> explicitly
> differentiate between the two, and as the lines blur, therein start the
> arguments
>
> Almost all but the most trivial programs have to keep track of
> state of some
> sort, whether that is of a physical device on a production line,
> bank account
> balance, user shopping card or whatever.  The key is what causes
> this state to
> change?  The receipt of an "event" (I'm using the term in a
> generic sense).
> The physical device tripped a sensor switch, a deposit was
> received or the
> user clicked on the "checkout" button.

The 'initial' state needs to be considered before events can operate! A
switch may have tripped before the embedded processor was powered up, a bank
account may have funds before the application was installed....

>
> My recent suggestion that we split the Context objects away from the
> Embedlet code (and not store state in the embedlet instance
> variables) is a
> manifestation of this.  The Context objects are responsible for
> keeping track of
> state.  The Embedlet Events (and code that produces events) are
> responsible
> for triggering state changes.  One is data-oriented.  The other
> is process-
> oriented.  And it's typically a "good thing(tm)" to keep the two
> separate and
> distinct in application design, since it makes for clean and
> maintainable code.

The state (in the simplest case) is the value of a switch input or the
result of a boolean operation on several inputs. It would not seem to make
sense to store this in any place other than the processing component - the
embedlet. The model for this is digital logic: Gates are state driven,
latches are event driven or synchronized by a clock. They co-exist, but the
designer has to be aware of initial conditions, race conditions etc.

Moving the state outside of the 'visible' embedlet realm seems artificial
and unneccesary. Some embedlets will be state driven and some event driven.
OR they may need to to function in a mixed environment.

>
> I think trying to choose one paradigm or the other is
> nonsensical, since you
> typically need both in any real-world situation.

My initial point was that there ARE mixed paradigms that need to co-exist
(my use of 'vs' was a little misleading). The solution that I am striving
for would have to accomodate both in a way that does not create mutually
exclusive requirements, indeterminate initial values or race conditions.

Maybe it is as simple as providing a mechanism for initial conditions to
propagate forward on start up. This would limit the requirement for 'reverse
chain logic' where an output has to 'look' all the way back into the logical
tree to determine a correct value. It would only have to wait for an event
and then 'look' at the immediate nodes and assume that they were current.

The problem that I see with this is that if an output is dependent on
several inputs each of which generates an initial event, the output could
change for each event, causing quite a bit of consternation in the chocolate
factory.

Hence my earlier suggestion of an initialConditions() method prior to
start(). This would allow initial conditions to propagate and settle prior
to asserting any outputs. The lifecycle sequence would then be:

1. constructor() - the embedlet constructor
2. addListener() - wire them together
3. initialize() - get ready, configure hardware/JAPL
4. initialConditions() - inputs fire initial events, outputs settle
5. start() - outputs asserted, inputs start generating change events
...
6. stop() - shut down event generation
7. terminate() - clean up your mess

>
>
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>