[opensource-dev] State machine class

Morgaine morgaine.dinova at googlemail.com
Mon Feb 15 06:43:54 PST 2010


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

> (sorry, but any 'secret' work that I never heard of before from whoever is
> working on it on this list has to be ignored),


Just because you haven't heard about something doesn't mean that others
haven't.

Lindens have mentioned their internal Firefly client-side scripting project
at several of their Office Hours now, for example at Q Linden's.  While the
project name and purpose are known, the details are a closely guarded
secret.

This is highly inappropriate given that it will determine the structure of
the open source viewer to which this list is dedicated.  It's treating the
opensource-dev community as nothing more than code and debug monkeys,
dancing to the LL design tune.  That's not a healthy relationship with open
source communities.

It's also out of step with claims that 2010 is going to see a new openness
from Lindens.  Firefly is a bad start.  Client-side scripting is one of the
most crucial features that the community should be discussing, because it
will impact on almost everything about the viewer.  It's massive.


Morgaine.




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

The most important aspect of any non-trivial software system is its design,
since that determines everything else.


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/9b894ff7/attachment.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/9b894ff7/attachment.gif 


More information about the opensource-dev mailing list