[opensource-dev] State machine class
morgaine.dinova at googlemail.com
Mon Feb 15 02:29:12 PST 2010
State machines are very useful, but the use case you gave is an example of a
user application that should be coded in an attached script. The fact that
the viewer does not yet have attached client-side scripting is not a reason
for putting the user application directly into the viewer. It's a reason
for adding client-side scripting first.
State-switching applications for the viewer would then become trivial to
write as a user process, in any language of the user's choice. We were
working on such a design for the viewer within AWG many moons ago --- some
details are given here, and the many advantages listed:
https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft . We
were also examining that kind of structure for user scripts in Imprudence:
http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png . We're
long past the refactoring sell-by date for this excessively monolithic
The viewer is buggy as a direct consequence of its size and bloat --- there
is no escaping that relationship in today's seat-of-pants software
methodologies. Adding more things into the main code should be avoided at
all costs, unless those things are central to its operation. Anything that
is not central should be factored out into attached processes, and this is
particularly true in the case of any facility that does not have a high
speed requirement, such as your example. It would avoid bloat and be much
The right question to be asking at this stage is why Lindens are currently
designing client-side scripting *behind closed doors* in their internal
Firefly project. *Secrecy in design should have no place in an open source
viewer.* In this instance it impacts directly on your suggestion, since
state switching is so easy to do in an attached user script.
I believe that Firefly should be stripped of its sekrit internal status and
the design addressed here in this opensource-dev community, where it
belongs. Given client-side scripting, adding a state machine into the core
code would then become moot.
On Thu, Feb 11, 2010 at 4:59 PM, Aleric Inglewood <
aleric.inglewood at gmail.com> wrote:
> Hi, with the eye on supporting plugins, I'd like to add a 'tool' to the
> A state machine.
> I'd add a base class from which others can derive their own classes.
> A new state machine would then be started by creating one or more objects
> of those types.
> It would be a class that supports a chain of asynchronous actions (and
> The object would run in the main thread and be called under the "Idle"
> header (fasttimers).
> The object will know an 'idle' state (when it's waiting for data) during
> which it will
> use no significant CPU.
> The user (developer, you) would provide an enum with states for your object
> and switch between states by calling a method (ie, set_state(new_state)).
> If it is necessary to wait, you can call the idle() method, which will idle
> until data is available (detected elsewhere) causing the state machine to
> continue the current state.
> As an example, consider a series of actions like walking to a certain
> creating a prim there (or rezzing something) and then sitting on it. Or,
> to do some calculation on a number of selected prims (for which you have to
> wait till all data of the selected prims has arrived). Well... the
> applications are
> limitless of course; just what plugins need ;).
> It won't be ALL that is needed for plugins, but it would be a good start,
> this isn't wirrten/available before someone starts to write something for a
> the wheel will be reinvented over and over again.
> Any comments? :)
> Policies and (un)subscribe information available here:
> Please read the policies before posting to keep unmoderated posting
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the opensource-dev