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