[Opensim-dev] RFC: Refactoring Scene.cs so that modules directly invoke services from CommsManager

[Teravus Ovares]

I detect a thread hijack!

This was about Scene.cs and CommsManager and moving stuff into it's
appropriate place.

Best Regards

Teravus

On 12/18/08, Hurliman, John <john.hurliman at intel.com> wrote:
> +1 on this. The only barrier to making everything grid mode has been that it requires more human effort to setup. Writing OpenSimStandalone.exe would be trivial (use the Process class to start everything with the proper command-line options and stream their output to the open console).
>
> John
>
> > -----Original Message-----
> > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> > bounces at lists.berlios.de] On Behalf Of Melanie
> > Sent: Thursday, December 18, 2008 2:25 PM
> > To: opensim-dev at lists.berlios.de
> > Subject: Re: [Opensim-dev] RFC: Refactoring Scene.cs so that modules
> > directly invoke services from CommsManager
> >
> > This is the point where we really should take a good hard look at the
> > usefulness of standalone as it is today. Transparently starting grid-
> > server sub-processes and having just one codepath in Scene seems to be
> > the cleaner way. Just let it treat everything as a grid from a
> > software POV and just present it to the user as if it was still the
> > old standalone.
> >
> > Melanie
> >
> > Teravus Ovares wrote:
> >> CommsManager was originally for the Inter-region communication.  It
> >> wrapped Grid Comms and single instance comms under one roof.
> >>
> >> You're planning on expanding that definition to region services?
> >>
> >> Best Regards
> >>
> >> Teravus
> >>
> >> On 12/18/08, Justin Clark-Casey <jjustincc at googlemail.com> wrote:
> >>> Teravus Ovares wrote:
> >>>> You would think that the service wrappers would be something that
> >>>> should go into scenebase, the scene base class as virtual.   The idea
> >>>> behind this is, 1.  it would be out of Scene.cs.   2.  It would be
> >>>> available, if someone intends on deriving another Scene class from
> >>>> SceneBase.
> >>>>
> >>>> Then again.  Maybe Scene is too complicated and encapsulates too much
> >>>> specific functionality to make it reasonable to expect someone to
> >>>> derive a separate class from SceneBase.
> >>>  Yeah.  I still am more in favor of switching everything to get
> >>> services through CommsManager (which may be slightly misnamed).  On a
> >>> little further digging, a lot of modules do this already, so we now
> > have this inconsistent situation where some stuff is fetch through
> > CommsManager and other things are done via CommsManager wrapping
> > methods on Scene.
> >>>
> >>> It would be nice to be consistent in this.
> >>>
> >>> Also, going directly to CommsManager may make it easier to get
> >>> services by interface in the future, instead of the existing
> > hardcoded fields (in the same manner as interfaces are registered on
> > Scene itself).
> >>>
> >>>>
> >>>> Best Regards
> >>>>
> >>>> Teravus
> >>>>
> >>>> On 12/18/08, Justin Clark-Casey <jjustincc at googlemail.com> wrote:
> >>>>> In Scene.cs there are quite a few wrapper methods that appears
> >>>>> to exist primarily to relay calls from modules to other services.
> >>>>> For instance, Scene.AddXmlRPCHandler() just recalls
> >>>>> AddXmlRPCHandler() on the BaseHttpServer.  Some modules make use
> >>>>> of this method while others use
> >>>>> Scene.CommsManager.HttpServer.AddXmlRPCHandler()
> >>>>>
> >>>>> I would like to refactor code such that services available through
> >>>>> CommsManager are called directly rather than through Scene wrappers.
> >>>>>  Although this goes against the Law of Demeter
> >>>>> (http://en.wikipedia.org/wiki/Law_of_Demeter) I think that the
> > advantage in reducing the large number of disparate methods on the
> > Scene is worth it.  The alternative is that the number of Scene
> > wrapper methods continues to grow indefinitely as new service methods
> > are introduced.
> >>>>>
> >>>>> Comments?
> >>>>>
> >>>>> --
> >>>>> justincc
> >>>>> Justin Clark-Casey
> >>>>> http://justincc.wordpress.com
> >>>>> _______________________________________________
> >>>>> 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
> >>>>
> >>>
> >>>
> >>> --
> >>> justincc
> >>> Justin Clark-Casey
> >>> http://justincc.wordpress.com
> >>> _______________________________________________
> >>> 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
> >>
> >>
> > _______________________________________________
> > 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
>