Hey Homer (since this is primarily addressed to you :),
I see you're making some progress on the up-and-coming new region modules
mechanism.
Instead of passing Scene itself to region modules, could we create an interface
so that we better control the amount of
innards that we expose to region
Hi Justin,
On Tue, Apr 14, 2009 at 7:02 PM, Justin Clark-Casey
wrote:
> ...
> Instead of passing Scene itself to region modules, could we create an
> interface so that we better control the amount of
> innards that we expose to region modules? It's convenient-ish to give the
> original Scene c
os.de
> Subject: [Opensim-dev] Supplying IScene instead of Scene for the future
> region modules mechanism
>
> Hey Homer (since this is primarily addressed to you :),
>
> I see you're making some progress on the up-and-coming new region modules
> mechanism.
>
> Inste
I'm not happy with supplying IScene. It would basically curtail the
functionality of region modules to what core believes should be
possible, and will lead to ugly upcasting "(Scene)IScene" that the
code is already rife with.
So, I'm not seeing that as a good idea at all, it limits things too
m
edia AB
>
>
>
>
>> Date: Tue, 14 Apr 2009 18:02:45 +0100
>> From: jjusti...@googlemail.com
>> To: opensim-dev@lists.berlios.de
>> Subject: [Opensim-dev] Supplying IScene instead of Scene for the future
>> region modules mechanism
>>
>> Hey Home
r 2009 20:32:48 +0200
> From: mela...@t-data.com
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Supplying IScene instead of Scene for the future
> region modules mechanism
>
> I'm not happy with supplying IScene. It would basically curtail the
> functiona
foundations for a
> > ISceneAPI, if you will?
> >
> > On my mind for a long time, both these things has been.
> >
> >
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> >
> >
> >
> >
> >> Date: Tue, 14
lly an indication that
>> you should have a 'ISceneForRegionModules' instead - an facade enumerating
>> the powers the core wish to expose to the scene, to force the region module
>> coder to code in a hygienic way. Laying the foundations for a ISceneAPI, if
>> y
pr 2009 18:02:45 +0100
> > From: jjusti...@googlemail.com
> > To: opensim-dev@lists.berlios.de
> > Subject: [Opensim-dev] Supplying IScene instead of Scene for the
> future region modules mechanism
> >
> > Hey Homer (since this is primarily addressed to you :),
&
in SceneGraph either...
>
> >
> > On my mind for a long time, both these things has been.
> >
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> >
> >
> >
> >
> > > Date: Tue, 14 Apr 2009 18:02:45 +0100
> >
e ain't a great name. But I'm not too keen on
>> ISceneForRegionModules either :). ISceneAPI perhaps...
>>
>> Of course, this also doesn't take into account the big lump of stuff hanging
>> around in SceneGraph either...
>>
>> >
>> > On my mind
numerated for smooth decoupling and encapsulation.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
>
>> Date: Tue, 14 Apr 2009 20:32:48 +0200
>> From: mela...@t-data.com
>> To: opensim-dev@lists.berlios.de
>> Subject: Re: [Opensim
Melanie wrote:
> Hi,
>
> as a mid to long range goal, +1, actually.
>
> but in the short run, the ability to load and unload regions is
> blocked by the existing module API, and to fix this basic piece of
> functionality, they need to be migrated to the new API, asap.
>
> If this is dragged in
ity, enumerated for smooth decoupling and
> > encapsulation.
> >
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> >
> >
> >
> >
> >> Date: Tue, 14 Apr 2009 20:32:48 +0200
> >> From: mela...@t-data.com
> >> To:
Better to keep it simple for now, but making a IScene is probably ok later on.
I did a quick grep through my region modules (extsim, load balancer, some
private stuff) and found that I'm using these functions. I'm sure other people
use more.
/Johan
scene.AddNewSceneObject
scene.AuthenticateHa
> scene.m_restorePresences
O.o
/Stefan
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
That member was actually introduced for the load balancer only, and
is not supposed to be accessed by anything else. But, it's a case in
point where a specialized application would not be possible if only
an interface were passed.
Melanie
Stefan Andersson wrote:
>
>
>> scene.m_restorePrese
v] Supplying IScene instead of Scene for the future
> region modules mechanism
>
> That member was actually introduced for the load balancer only, and
> is not supposed to be accessed by anything else. But, it's a case in
> point where a specialized application would not be possi
Sean Dague wrote:
> Melanie wrote:
>> Hi,
>>
>> as a mid to long range goal, +1, actually.
>>
>> but in the short run, the ability to load and unload regions is
>> blocked by the existing module API, and to fix this basic piece of
>> functionality, they need to be migrated to the new API, asap.
>
Looks like you didn't read my post. I said, as a mid to long range
goal, yes. I didn't say we should never have it. I said it would
block critical fixes if it were forced onto the new region module
interface now.
I'm not bullying anyone. You have not yet had the pleasure of seeing
me bully anyo
Melanie wrote:
> Looks like you didn't read my post. I said, as a mid to long range
> goal, yes. I didn't say we should never have it. I said it would
> block critical fixes if it were forced onto the new region module
> interface now.
In your earlier posts you vehemently decried any notion of
The important turning point of the discussion was when the talk
turned to splitting things out of Scene. I'm still dead set against
hiding Scene as it is today behind an interface, because it would
turn into just as unmaintainable a behemoth as IClientAPI is.
However, breaking things out of Scen
Melanie wrote:
> The important turning point of the discussion was when the talk
> turned to splitting things out of Scene. I'm still dead set against
> hiding Scene as it is today behind an interface, because it would
> turn into just as unmaintainable a behemoth as IClientAPI is.
> However, br
23 matches
Mail list logo
