> > this is why now all code is public and following few step you can > contribute all code you want... a optional switchable theme/UI/XUI can > be merged giving to all residents the freedom to choose the aspect on > monitor (viewer 1.x style too). > > Is hard take LL base code, patch it, merge a LL-next-version to fit > newfeatures and patch again everything, i think this way to work is > great why all can fit a features (a single click in setup panel > enable/disable it maybe...) without care to merge everytime a new > features will be implemented by LL
Like I said... lots of ideas, but not enough geek nor enough singlehood to commit as much time to this kind of thing as it would need. It's like looking through the window at some Shiny Animal you might be able to buy and dearly want, but you could never afford to feed and you know it. It makes me sad, heh. The base idea for the GROND project was only a plugin manager, memory/data manager, and these basic plugins: 1. A UI plugin. Allows for hot-loading a UI and handles all human I/O that isn't related to rendering or audio. 2. A viewer plugin. Allows for hot-loading renderers since all scene information is maintained by the data manager and not the renderer library. 3. A protocol plugin. Would allow for protocol upgrades to occur on a per-grid basis.Each grid could provide a plugin or just a protocol spec to handle their own grid's communications needs, so that things like SL 2's incompatibility with OpenSim doesn't have to happen again. That was a HUGE pain trying to get used to 2.0 on my own grid... it just didn't work. Some extras I came up with were: 1. An audio plugin. This plugin could handle all audio input and output to and from the viewer. This would permit the use of voice (VOIP) technology as well as play inworld sounds and streaming. Doesn't have to only be audio, could be a "direct gstreamer" plugin. If it ate too much bandwidth, it could be unloaded by the user or just self-throttled. 2. A client-side physics plugin. This plugin would handle all soft-body physics to be displayed by the viewer. Note that all rigid-body physics must be simulated on the server, with the collisions only reported to the client. If it ate too much processor, it could be disabled. 3. A local filesystem plugin. This one's cool. Upload / download from within an inworld object or from your own inventory - which could display your own local filesystem as well as your inworld inventory. This kind of thing could easily evolve into the first viable 3D desktop that could also integrate emerging web technologies and do it completely transparently. But like has been said, it's HUGE. There's no WAY I could devote enough time to it. It's the next Mosaic, and LL's already written the first versions of all of the most important parts. --GC _______________________________________________ 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
