We need a standard API for to this to work well. I wouldn't expect a formalized standard to happen quickly, but an API no doubt is needed at least.
We can treat the network code now in the viewers as part of the Agent Domain. It probably didn't appear like that before, yet with the API it certainly does. I guess some didn't take an API seriously because they thought it disabled or prevented user interfaces already present in the viewer. This show that an API doesn't disable or prevent any user interfaces already present in the viewer: http://jira.secondlife.com/browse/SNOW-375 As the API develops into a more truer RESTful scheme, then client-side scripts could run in each of there own process without the need to be a directly plugged into one another (or compiled together). This is a very scalable approach. Here, the network code acts in the viewer acts as a hub for the Agent Domain (a subset of it until more formal). If you look at the code for the World Map, the viewer updates the script of the position, but then the map uses HTTP to fetch the textures. Even without any code being disabled/prevented in the viewer, you can expect that the viewer would not have to chew on texture fetches, which would mean more time it can spend to actually render the scene. This is more so true on multi-core machines. The AO ability is certainly possible. SNOW-9 was a stub for gesture recognition, but it could easily use this API instead. There is different ways to achieve this, and I thought simplest way would be to like wear animation/gestures much like one wears clothes, or maybe something like the interface for attachments. Probably more of interest than an AO right now is to have LSL-editors use the API. When you open a script in-world, it would actually open your client-side script/program of choice to edit. There are some good ones out there. I've said too much... (not really *wink*) Lillian Yiyuan wrote: > More on topic for the viewer. Many of that activities currently > performed by scripts should be done primarily out of viewer resources, > these include, but are not limited to, AOs, radar, scripts on > attachments, flight enhancement and so on. One short road to making it > so that script limits are not noticed, is to take off the server the > long list of activities that are server side, but do not need to be > there. If most avs can wear their clothes and their AOs and a few > gadgets, they will not notice scripting limits, and there will be more > resources for physics, graphics and so on. Client side scripting is > not easy but there have been enough implementations of it in various > places to show that it is practical and not fatal to sim performance. > > Many of these enhancements have already been put in to open source > clients, and therefore are good targets for implementation. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
