Mikko Pallari wrote:
Hi,
Was there some particular reason why the OpenSim.32BitLaunch.csproj was
removed from trunk? It has been previously found very useful:
http://teddmaa.blogspot.com/2008/12/opensim-in-visual-studio-on-win64.html
as alan said, no, there wasn't aside from me doing a
Internally, they should be case sensitive, but in talking to the
client, it should be treated case-insensitively.
Melanie
Jeff Ames wrote:
Hello,
Should region names be case-sensitive? OpenSim currently seems to
treat them as such, e.g. in RequestClosestRegion.
For the start location
It may seem that by supporting as many of these as possible its making the
task easier for the client, but I believe making a very generic version of
option C, allowing each region to be customised to require varying levels of
protection and pushing back the ease off use issue to the client
It seems you're forgetting the valid use case of multi-server sites.
Ultimate trust within a domain (today's Grid) is a valid use case.
Melanie
DZO wrote:
It may seem that by supporting as many of these as possible its making the
task easier for the client, but I believe making a very
Melanie wrote:
They are very different. A key is specific for one client-server pair.
So for each region the client visits there is a unique key that the
other regions might not know about. When TPs are performed on the
server-side, this is equivalent to (b) because the regions are acting
One of the really interesting things about OpenSim, at least for me, is
its goal of becoming a framework for VW application development. Yes,
OpenSim has Second Life as the reference application, and it's really
easy to forget that SL is just a reference. And as we identify the
weaknesses of
Michael Cortez wrote:
Any particular reason why the system could not use the SessionID
(established for the source region) to validate the user as they
transfer to the destination region -- but once validated, a new
SessionID is generated for the target region and the old SessionID
And while this kind of spoofing may look absolutely scary in the context
of a web of VWs, it may be a feature in game applications.
Diva Canto wrote:
Michael Cortez wrote:
Any particular reason why the system could not use the SessionID
(established for the source region) to validate the
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
jjusti...@googlemail.com 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
Justin, Homer;
consider two things you might:
1) take the opportunity to take a moment to re-ponder each missing IScene
power - should the caller perhaps move instead? Or should the called method
move to a place where the caller has access without going thru IScene? Maybe
the Scene is
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
A few points to consider:
- Should core really limit what _can_ be done by non-core module coders?
- Is it very likely that anyone would make a new Scene-type object
without inheriting from Scene?
I believe that passing Scene directly is the right thing to do, as
the region modules'
Um,
I believe you're saying supplying a smaller subset of the functionalities of
Scene, as being able to supply something else than a concrete implementation
should never really be a problem - in fact, in most cases supplying an
interface is more desirable.
That said, what I was
- Should core really limit what _can_ be done by non-core module coders?
Yes. And in what sequence, and in what ways. That is what programming is. That
is what designing is. And it's how you help people understand the intended use
of an API.
We've already done that in Scene. Some things
Melanie wrote:
A few points to consider:
- Should core really limit what _can_ be done by non-core module coders?
- Is it very likely that anyone would make a new Scene-type object
without inheriting from Scene?
I believe that passing Scene directly is the right thing to do, as
the
I have some great ideas for region modules... and..I don't
have the time to do them over and over again when the API changes AND
work on OpenSimulator too.
This has been one of my 'showstopper' reasons for not working on some
region module ideas that I have.
So, if we're going with an
This entire discussion is, of course, moving away from the thing
that started it all.
The original plan was to make a region module API that is able to
support dynamic loading and unloading of regions, then quickly
convert all modules to that API.
If we now go into ISceneAPI and loads of
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 into a long architectural
Hell, +1 on solving the issue at hand without going into long architectural
discussion.
Just chipping in. :D
Best regards,
Stefan Andersson
Tribal Media AB
Date: Wed, 15 Apr 2009 00:37:58 +0200
From: mela...@t-data.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev]
Esteemed Testers and Developers,
As you may know, the current lean release cycle handling defines testers and
developers as anybody feeding off trunk so if that's you, I have a favour to
ask;
it's time to gather round and try to nail down a good candidate revision for
0.6.5. Ideally,
On Tue, Apr 14, 2009 at 9:28 PM, Stefan Andersson ste...@tribalmedia.se wrote:
Esteemed Testers and Developers,
As you may know, the current lean release cycle handling defines testers
and developers as anybody feeding off trunk so if that's you, I have a
favour to ask;
it's time to gather
Please post that log to a mantis, everything compiles perfectly for me
on windows with head.
~T
Robert Martin wrote:
On Tue, Apr 14, 2009 at 9:28 PM, Stefan Andersson ste...@tribalmedia.se
wrote:
Esteemed Testers and Developers,
As you may know, the current lean release cycle handling
Internally, they should be case sensitive, but in talking to the
client, it should be treated case-insensitively.
Okay. I don't have time to work on this at the moment, but I added it
to mantis so it doesn't get lost:
http://opensimulator.org/mantis/view.php?id=3457
Jeff
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
25 matches
Mail list logo
