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

[Justin Clark-Casey]

On 15/11/12 14:39, James Hughes wrote:
>>
>> * 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.

What about modules that want to listen to two separate ports?  Would they be two separate connectors?

>
>> * 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 guess my question is why this ini data isn't already in the named config directory when the connector is downloaded 
from the repository.  Why does there have to be a separate step to fetch this ini?

These are really detail questions that can be sorted out after the fact - personally I'm happy to see a merge of this 
branch to get more eyes on it.

>
>> 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
>>>
>>
>>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>


-- 
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc