[opensource-dev] State machine class

Morgaine morgaine.dinova at googlemail.com
Mon Feb 15 07:09:05 PST 2010


On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood <
aleric.inglewood at gmail.com> wrote:

> 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.
>


**IFF** a state machine is required infrastructure in the viewer code before
client-side scripting can be implemented, then I agree with you
wholeheartedly.  That claim has not yet been justified though.  I would be *
very* interested in seeing a design for client-side scripting that is based
on a core state machine.

The designs that I have been looking at do not require a state machine,
because they use a stateless core.  All state is maintained in the scripts
themselves, and the viewer core doesn't need to be concerned with their
state.  It's much cleaner because the scripts can use normal blocking calls
in normal languages --- all that comes for free with external processes, and
benefits automatically from multiple cores.

It's not the only way to skin a cat though, so I welcome discussion about
alternative approaches.  Assuming of course that Lindens open up the design
process for client-side scripting in the first place ...


Morgaine




============================================

On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood <
aleric.inglewood at gmail.com> wrote:

> 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.dinova at 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.inglewood at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100215/6c2fc546/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 96 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100215/6c2fc546/attachment-0001.gif 


More information about the opensource-dev mailing list