Plugin architecture; was: [sldev] Avatar list ready for testing!

[Tateru Nino]

Hmm. How about this? The plugin subsystem gets a feed of decoded 
messages forked from the network handlers. It can either use some 
interest-list/registration system, or just spew messages raw to the 
plugin and expect each plugin to discard what it is not interested in - 
as a preliminary measure. Additionally the viewer should be able to 
inject messages of it's own, destined for the plugin subsystem. This 
could indeed be done with a socket or local network port.

The plugin subsystem in turn can generate messages to be injected 
asynchronously back into the viewer, either to trigger the viewer itself 
to take an action (make your own list of local actions and expand as 
necessary), or to generate a message to return to the grid via the 
data-stream (more based on what actions the viewer can take via the 
network protocol).

Sure...it's cheap. In its simplest form, its potentially grossly 
_wasteful_, even. But heck, if you _really_ wanted a cheapass bot, plug 
a python script, have it tell the viewer to 'stop rendering' (to save 
all those CPU cycles, same as minimise mode), sit back and let python drive.

Potentially, it could be used as a stopgap for exploring just what sort 
of facilities and layered interfaces you _want_ in a plugin architecture.

Dale Glass wrote:
> В сообщении от 21 февраля 2007 17:38 Mike Monkowski написал(a):
>   
>> But maybe you could answer a question I've been trying to figure out
>> concerning the plugin discussion here.  I can understand in a browser
>> how plugins can be inserted in the stream of data and act as a filter
>> for specific file types.  Would this mean that the SecondLife plugins
>> would be inserted in the message stream between the client and server?
>>     
> Something like that, although considerable work is needed here. For example, 
> take my scanner. It queries the avatar's payment info and birth date. Now, 
> when the reply arrives, the client gets a packet of the AvatarPropertiesReply 
> type. A plugin would have to register itself and say "Hey, I want to know 
> when one of those gets received too". Except that in the current code there 
> can be only one handler per message type, so that will have to be fixed.
>
>   
>> Or would they work off of the local cache?  Or would they reference a
>>     
> Definitely not, there's not much you could do with that and it'd be ugly too.
>
>   
>> class that had accessors for each of the global variables?
>>     
> A bit of everything would be needed. A plugin needs to be able to tell the 
> viewer that it's interested in certain types of packets. It has to be able to 
> access some internal state (avatar list, say). It's got to be able to do 
> things like creating windows, sending commands to the sim, etc. Quite big 
> changes are needed here.
>
>   
>> Mike
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>>     
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>>     

-- 
Tateru Nino
http://dwellonit.blogspot.com/