[Opensim-dev] Robust dynamic connector plugins...

[James Hughes]

On 11/10/2012 12:48 AM, Justin Clark-Casey wrote:
> Hi James. Sorry it's taken so long for me to reply, various work
> pressures and other stuff.
>

No problem - same here :)

> Yeah, personally I'm happy going with Mono.Addins. As you say, we're
> already using it and going with the MEF would mean rolling a repository
> system. Also, I see some talk that Mono.Addins could just use the MEF as
> it's underlying basis in the future anyway.
>
> Now some other points.
>
> * IRobustConnector appears to assume that all ROBUST plugins implement
> HTTP handlers. However, some plugins may just provide extra debug
> console commands (some such region plugins exist already) or extend
> other plugins (and thus don't implement their own handlers). How would
> these work? This would also be a problem with
> IRobustConnector.Configure() passing back a number for the listening port.
>

These are full connectors. Previous work allowed dynamic loading of 
services into a connector. So, it is assumed that we will be using or 
creating a port on the http server. I think we would be able to create a 
plugin that just handles console commands too. We should be able to pass 
0 as the port if we want to use the default server port or do not desire 
to use one.

> * Why provide the option to pull down a bootstrap.ini? This seems
> overcomplicated to me but perhaps an example would make it clearer. And
> writing this data to an existing ini file makes me a bit nervous, esp.
> on windows since, for instance, the write could fail if the user also
> has the file open.
>

This is a "last ditch effort" to provide a configuration. The normal 
Robust.ini is looked at first for the configuration section, then if not 
found, the plugin looks for it's file in the named configuration 
directory. If no file is found, then it will pull it's configuration 
from the repository. The user may then edit that file, or copy the 
contents to the Robust.ini and cycle the enable/disable on the plugin to 
run it.

the way things are currently distributed, we supply a snippet  of text 
for the user to paste into their ini. If they do that ahead of time, 
then the system will use that instead of going for the bootstrap ini.


> * I think IRobustConnector would be better named
> IRobustServerInConnector or similar to match XInventoryInConnector,
> GridInfoServerInConnector, etc. in OpenSim.Server.Handlers. I like the
> *InConnnector because this better distinguishes the inbound ROBUST
> handlers from the simulator outbound requests (which are also called
> connectors and are, as we know, in OpenSim.Service.Connectors.
>

OK, sounds good to me. Will make that change.


> In fact, I would personally prefer to see the *InConnectors called
> something different to make the difference with the outbound connectors
> much clearer in the code. However, nothing springs to mind - perhaps
> InConnector is good enough.
>
> Of course, this isn't helped by the inconsistency in
> OpenSim.Server.Handlers naming (where most are just named
> ServerConnector). Or the fact that these extend ServiceConnector (which
> implements IServiceConnector) but yet are in a file named
> ServerConnector.cs.
>
> * From your previous e-mail, I think it would be better to start off
> with the specific interface for dynamic plugins and then look at
> modifying IServiceConnector once the code is in core and the
> implications are understood.
>

That would be good. Once it is merged, then more eyes on the code will 
help provide ideas to make it better.



> * I certainly think it would be good to extend such a system to region
> modules. But I think there are various issues there which I'd prefer to
> discuss at a later point rather than extend this e-mail.
>

Yes, I would like to make as much of it as possible fit into a generic 
service that could be re-used.

> I also took the liberty of updating
> http://opensimulator.org/wiki/Feature_Proposals/PluginManager with
> instructions, etc.
>

Thanks for that. I will make the changes and update the branch. If all 
looks well, we can merge it soon. Diva has been looking at a way to 
distribute her modules and it would be a good chance to optimize it.

Thanks,
BlueWall

> Best,
>
> Justin
>
> On 27/10/12 04:11, James Hughes wrote:
>> Fortis used it and it didn't seem a lot different than the way we have
>> been using mono-addins in OpenSim.exe to this
>> point. MEF uses attributes to define, as does most of addins. Some
>> things in mono-addins still need to be defined in the
>> xml manafest files, but most things can be done by attributes. MEF
>> supports management of local assemblies and it
>> doesn't provide tools for repositories and assemblies like
>> mono-addins. Using MEF would require the additional
>> development of those tools. So, the feature set of mono-addins is more
>> complete for this type of work. We already use
>> mono-addins extensively in the region server and it has served us
>> well. It seems that some miss-steps were made in the
>> implementation and need some refactoring (possibly newer versions have
>> resolved issues that caused us to have these
>> workarounds?). But, all in all we have had good results and have a
>> great deal of the work toward managing remote
>> repositories and plugins in the region server done as well. Even if we
>> were just dealing with local assemblies I would
>> see no real technical advantage to using MEF over mono-addins.
>>
>> The mono-addins project is part of the mono git-hub code and has been
>> headed up by Llouis Sanchez, one of the lead Mono
>> developers with Xamarin. And it is used in Monodevelop that is the IDE
>> of their commercial products. So, its heritage is
>> OK and it is actively developed.
>>
>> Thanks
>> BlueWall
>>
>> On 10/26/2012 07:32 PM, Justin Clark-Casey wrote:
>>> My first question is, what do you think of the alternatives to
>>> Mono.Addins, chiefly MEF (Managed Extensibility Framework)? How do they
>>> compare?
>>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>