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 client. 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 more flexible. 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. Morgaine. ====================================== On Thu, Feb 11, 2010 at 4:59 PM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > Hi, with the eye on supporting plugins, I'd like to add a 'tool' to the > viewer: > 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 > queries). > 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 > place, > creating a prim there (or rezzing something) and then sitting on it. Or, > wanting > 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, > because > this isn't wirrten/available before someone starts to write something for a > plugin, > the wheel will be reinvented over and over again. > > Any comments? :) > > Aleric > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
