Rob, sockets do not add any bulk to a *viewer* at all, since the socket code is already present in every viewer. What's more, the suggestion of bulk doesn't even make sense in the context of directly embedding Lua in the viewer, since embedding Lua will grow the viewer by the size of the Lua interface at the very least. Lua is really small and has very simple interfacing requirements, but even so, that's infinitely more bulk than the zero additional bulk of sockets. :-)
Of course, outside of the viewer, plugins implemented as external processes do carry that extra bulk, but in exchange you get an immense number of good things. Principle among them are hardware MMU-guaranteed process isolation, free harnessing of multiple cores, almost total absence of the many hard problems of concurrent multiprogramming, and total language agnosticism so that everyone is happy. The tradeoff here is completely in favor of socket-connected processes. And there are many more benefits. Rob, you may not have seen the following before, but I described in some detail the problems with Direct Language Embedding in a reply to Ricky on 8th March<https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000625.html>. I recommend that you examine that email because it factors in decades of experience with the very hard problems of concurrent multiprogramming, which you are completely ignoring. A multiprogrammed system for concurrent Lua programming is a completely different beast to normal Lua embedding. I like Lua a lot. Although it would present far fewer problems than Mono in an embedded role, embedding a language runtime is still the wrong approach for this job. It would bloat the viewer, create a huge multiprogramming problem, encumber development with years of concurrency headaches (I'm not joking), and impose a large number of constraints on scripts that will effectively hobble them and annoy expert programmers just like LSL does. None of this is necessary. It's a very bad package deal, while socket-connected plugins have none of these issues. Morgaine. =================================== On Wed, Mar 17, 2010 at 9:42 PM, Rob Nelson <nexisentertainm...@gmail.com>wrote: > As stated before, sockets add unnecessary bulk to any plugin > architecture, ESPECIALLY HTTP. The SL viewer currently takes up 100% > CPU even with scripting turned off; The last thing we need is more > memory or processor load. > > There are ways to signal the viewer when an event has occurred without > using sockets, and without running a separate process. A simple > std::queue of events being passed to the Lua engine is what I currently > use. I therefore suggest C++ Dynamic Shared Objects, each providing a > language option (Lua, Python, Mono), but with a shared interface that: > > * Provides public start/restart/kill methods (for a scripting console) > * Is in its own thread (to prevent blocking) > * provides a way to pass in events with variable arguments (Luna uses a > string stream with serialized objects) > * Provides the scripting engine some basic "environmental > variables" (Viewer name/channel/version, settings THAT ARE NOT > PASSWORDS, some other global vars like gAgent) > * Automatically starts (if configured to do so) only AFTER login to > prevent receiving login details > * Does not provide a way to create raw messages or send money. > > There's probably a bunch of other requirements, too. > > If firefly is truly using Mono, then I do sincerely hope it fails. Mono > is way too slow to run plugins efficiently, and as seeing that the > viewer is already chock-full of slowness, I don't want any more overhead > added. > > Rob Nelson > Luna Viewer > http://luna-viewer.googlecode.com/ > > On Wed, 2010-03-17 at 10:50 -0500, Argent Stonecutter wrote: > > On 2010-03-17, at 10:21, Dzonatas Sol wrote: > > > Ricky wrote: > > >> So far, barring any LL concepts, we have (as far as I know so far!) > > >> two designs of plugin system: > > >> 1: Socket-based plugins - as�suggested�by Morgaine. > > >> 2: D-Bus or similar existing IPC tool. > > >> 3: C++ Dynamically Shared Objects - my suggestion. > > > > > > 4. REST/HTTP > > > > That's just a specific design for category 1. > > > > _______________________________________________ > > 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 >
_______________________________________________ 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
