Re: [opensource-dev] Client Plugin System Design

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 inter

Re: [opensource-dev] Client Plugin System Design

Rob Nelson 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. Please, go ahead and benchmark how SNOW-375 h

Re: [opensource-dev] Client Plugin System Design

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

Re: [opensource-dev] Client Plugin System Design

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

Re: [opensource-dev] Client Plugin System Design

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 -

Re: [opensource-dev] Client Plugin System Design

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 The REST based syste

Re: [opensource-dev] Client Plugin System Design

On 2010-03-08, at 10:06, Morgaine wrote: > Unfortunately, as you know from your own work, Rob, there is a big > difference between using an embedded language inline with its host > application's main or single thread of execution, and turning the > language into a concurrent execution environ

Re: [opensource-dev] Client Plugin System Design

Indeed, Lawson. You may have seen it, but I provided a little more detail about accelerating plugin communications using Shared Memory segments in my answerto Tigro. In practice it's not easy to come up with an SM-accel

Re: [opensource-dev] Client Plugin System Design

Morgaine wrote: > > > PS. With regards to "Networking code in every plugin just to connect > to the client", networking is made available by the operating system > to every process through system calls or system subroutines, ie. the > thinnest interface possible. There is no bloat or overhead i

Re: [opensource-dev] Client Plugin System Design

Yes, there is a way, Tigro. In the Multi-Process Clientdesign that we started back when AWG was active, we loosely defined "Facility Optimization", which would be done mainly through communication * accelerators*. The general ide

Re: [opensource-dev] Client Plugin System Design

Lua provides a fine example of Direct Language Embedding. The language was designed expressly for being embedded in a host application as well as for being extended with calls to other languages. It's no surprise then that it is very clean and simple to use in this way. I like Lua a lot. Unfort

Re: [opensource-dev] Client Plugin System Design

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Would there be an approach that would allow both all the benefits you mention, plus letting the process based plugins have access to the bare metal performance? (somthing like a way to have the plugins instruct the client to add the desired processing

Re: [opensource-dev] Client Plugin System Design

On Sun, 2010-03-07 at 18:19 -0800, 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.

Re: [opensource-dev] Client Plugin System Design

Ricky, I'm not sure even where to begin, because your proposed solution is simply direct embedding of one or more scripting language systems into the address space of the viewer. This ignores every single advantage of process-separated plugins and replaces them with a catalog of problems that coul

[opensource-dev] Client Plugin System Design

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. Morgaine's design has a couple advantages that I can think