[Grok-dev] Grok/Zope Technologies for State Machine

[PAW]

Hi,

Over the last 6 months I've been researching and thinking about implementing
a (semi) distributed state-machine framework (in my spare time). The
investigation has led me to the decision to base the whole thing on
Zope/Grok. This is because I envisage the ZODB playing a central part in the
application, and it seems somehow natural to publish objects using Zope.
Furthermore, the component-based aspect appears to be a natural fit for a
'state' based system, whereby states are just special components providing a
certain interface. After looking at Grok and Zope, and all the functionality
available, I feel my head is about to explode.  So I'm writing in the hope
that someone could provide a little guidance on how to progress. I have
developed a confidence and allegience with grok however, because a like how
Martijn Faassen speaks about framework design, and martian configuration
fits my head so much better than using some separate configuration language,
etc... 

Firstly, the architecture in brief. The way I see it, developers will write
states classes that provide an interface IState that I've actually written
as:

# A loose description of what it is to implement 'state-ness'
class IState(IDrawable):
    """
    A state interface contains the necessary components
    to be instantiated with a dictionary parameter and
    have the method 'action' be called on it to proceed.

    action : Must return an object from the symbols attribute
    symbol : Contains the full list of all possible results
             from this state. This can be used by the runtime
             for interface checking purposes, but more
             importantly, can be used by a graphical editor
             to draw the object with its transitions in place.
             A static verifier may also use this attribute to
             check whether transitions have been described for
             all possible return symbols.
    """
    symbols = interface.Attribute(""" The list of symbols that the """ \
                                  """ state can generate. """)

    def __call__(params=None):
        """ Create a state object with the given hashable. """

    def action():
        """ Perform some action during the state's life. """

At configuration time, the system will find all classes that the developer
has implemented that provides IState, creates an object from them using
__new__, and stores them at some well known location in the object database.
(Is it possible to do this at runtime, perhaps using pynotify to check when
the directory changes?)

A developer will also write a transition table, but this will be written in
a graphical way using the same sort of system as Plone's
collective.workflowed. The table will also provide a dictionary of
parameters that are passed to the states via __init__(). The statemachine
runtime will initalise and run the object (using action()) and then leave
the object to get garbage collected. If the state is encountered later, the
object is reinitialised with fresh params. I imagine the transition table
will be a model also, providing a rich set of transition manipulating
functions, along with supporting views. 

There is also the concept of a substatemachine. This is just a link to
another transition table, that gets a param dict and returns some symbol
like any other state. (The difference being it is defined by futher states
and perhaps substates). 

I'd also like developers to be able to provide views on their state objects
in the ZODB in order to alter certain parameters of execution at runtime, or
maybe view statistics (or whatever). As the system matures, many other views
will provide runtime information about the runtime's functionality. There's
a bunch of other functionality that's not really worth mentioning. I hope
you get the idea. 

Initially, I envisaged that the runtime would be very separate from
grok/zope etc..., with grok just storing and publishing objects. However,
the long arm of grok appears to be influencing my runtime design too! How
so? Well it would be quite nice to allow developers to write event handlers
for events triggered from external sources or by application code. Maybe
acquisition could be useful too somehow? 

I've hit the point where all this has become a bit too much for me. Can
anyone validate my design? Suggest how grok may help in other areas? Also,
how do I approach building a package that will become a facility for
building a package? What tools should I be looking at here. 

Sorry for the long mail, and thanks for getting this far! 

Any help / comments would be warmly received!

Thanks,
Paul

-- 
View this message in context: http://www.nabble.com/Grok-Zope-Technologies-for-State-Machine-tp20113842p20113842.html
Sent from the Grok mailing list archive at Nabble.com.