On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglew...@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.inglew...@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.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
