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
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
