Ambroff, adding a specialized interface just to support an IDE is a very bad idea. It's a completely non-scalable approach, very inflexible, and it is simply too much work to add bespoke code each time a new application is wanted. And worst of all, it doesn't allow the user community to add their own applications freely, since it requires internal viewer changes each time.
This is why we were discussing generic client-side scripting here last month, both for viewer extensions and for world enhancement<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000173.html>. There is quite of lot of history in this area among viewer developers already, as various groups have been examining the issue. In AWG we looked at the general area of refactoring viewer functionality in the Multi-Process Client<https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft>concept, way back, which split everything into communicating plugins. Two or three 3rd party viewer teams (notably Emerald) experimented with an embedded Lua console, so they have some experience with language VM interfacing to a viewer API. And in Imprudence, we spent some months designing a language-agnostic plugin system<http://imprudenceviewer.org/w/images/4/48/Plugin_system_flow_APIs.png>that allows plugins to be written in any language that supports sockets, using JSON as the lingua franca for communicating with viewer API functions and callbacks -- see the threads labeled "[Plugins]" in the Imprudence Forums <http://imprudenceviewer.org/forums/viewforum.php?f=7> for more details. We even tested the limiting bandwidth and latency for such a plugin system just to be sure that we were on solid ground. This is the kind of infrastructure that would support IDE applications with great ease, without requiring internal viewer modification for each new type of external application. Once the basic plugin communications engine is in place, all that is needed is to expose everything of interest in the viewer as a Viewer API, and map incoming message names to API functions. Various people have also suggested that a hierarchical dataspace equivalent to a browser DOM could be defined in the viewer, so that viewer data can be accessed by scripts in a clean symmetrical fashion, which makes a lot of sense. There is an internal Linden project (Firefly) looking at client-side scripting as well, but that is being designed behind closed doors to fulfill some unknown internal Linden requirement. That's fine for the official Linden viewer of course, but it is not sufficient for the community viewer that is Snowglobe. Here we need a lot more, which last month's thread started to enumerate. We also need an open design process, because there are a lot of clever people on this list with insights on how best to tackle it, and a lot of different requirements will need to be met. And just on principle, design secrecy has no place in an open source community viewer project anyway. Morgaine. ===================================== On Thu, Mar 4, 2010 at 8:28 PM, Ambroff Linden <ambr...@lindenlab.com>wrote: > On Wed, Mar 3, 2010 at 7:03 AM, Jonathan Irvin <djfoxys...@gmail.com>wrote: > >> I do often hear complaints and wishes for new build tools, what about us >> LSL devs? Some things I would like are: >> >> 1. Better IDE in SL Viewer >> 2. API for compiling in LSL using various IDEs already available >> 3. Going along with #1, as suggested, integrating Eclipse or >> equivalent in SL. >> 4. LSL Wiki built into the editor >> 5. Detachable script editing window (To develop on one monitor & test >> in the other) >> 6. Entity relationship diagram system in SL viewer for visual coding. >> >> I'm not sure that spending whole lot of time adding fancy features to the > built in LSL editor is that productive (we aren't trying to build an IDE, > and there are a ton of really good extensible IDEs out there already), but I > really like your idea of putting together an API. Someone could hack a > service into the viewer that lets another process (like Eclipse or > Monodevelop) perform limited operations on the inventory of the currently > selected object. > > We already have D-Bus <http://www.freedesktop.org/wiki/Software/dbus> > integration > in the GNU/Linux Viewer for SLurl support, so it shouldn't be too hard to > expose something like an ObjectEditorProxy. It could allow an extension for > your favorite IDE to enumerate the scripts that are editable in the > currently selected object's inventory, fetch their contents, compile(), and > add new scripts to the object's inventory. The IDE could also subscribe to > events emitted by the viewer, such as ScriptAdded, ScriptDeleted, etc. > > What might improve the situation quite a bit is if the server supported a > capability that allowed the viewer to fetch all symbols exported by the > simulator (all LSL functions and constants). That metadata could then be > exposed to the IDE through the ObjectEditorProxy for intellisense support. > > In the long run I don't know if this is a good solution, but it would > certainly be an interesting experiment! > > -Ambroff > > _______________________________________________ > 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
