Morgaine, I *completely* agree with you! [?] One of the two main reasons, if not the only two, that we need this state machine approach *is* for client-side scripting and for plugins. Both are infinite flexible in nature and require in principle hooks into the viewer code to *control* the viewer on a level that goes way beyond a blocking function call.
The best approach to look at this is the following: If we have to wait for a server packet, it blocks. Currently there is no general way to wait for server-packet-events, hence you *cannot* implement client-side scripting. The state machine is so core and so basic, it's the core at the basis of much MORE code that is needed before you can even start to implement client-side scripting. Thus, since it was always my main goal to use this for client-side scripting (and sorry, but any 'secret' work that I never heard of before from whoever is working on it on this list has to be ignored), I assume you now agree with me that this would a great thing to have, since it will make it possible, in the end to provide hooks into the viewer in The Right Way(tm) that will allow us to write a client-side scripting implementation, which in turn will allow plugins to be able to actually control the viewer. I don't HAVE client-side scripting yet, so I have written code that uses this state machine on a higher level, but that was just to get a feeling of what is needed. I think I'm now ready to write that base class. On Mon, Feb 15, 2010 at 11:29 AM, Morgaine <morgaine.din...@googlemail.com>wrote: > 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 >
<<330.gif>>
_______________________________________________ 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
