Hi all,
right now script states are kept in a directory ScriptEngines.
Loosing script states is getting a little bit pain in the neck. Some script
don´t start without a manual reset for unknown reasons, other scripts don´t
get on their feet again by design. So you have always some
Sim states can't be reliable preserved between updates at the moment, because
if we make any form of API change in the script engine, the states are
invalidated.
Regards
Adam
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Ralf Haifisch
Test region: 40,000 prims (or there abouts), running trunk. Testing a
combination of factors including idle running, idle running with an avatar, etc.
Random notes herein:
- SceneGraph.Get* methods are generally very wasteful. Lots of them
use the /slow/ GetEntities method to build a
Not really knowing what I'm talking about, but; we still don't handle inventory
versioning correctly, so maybe it's as simple as that?
Best regards,
Stefan Andersson
Tribal Media AB
Date: Sun, 22 Feb 2009 22:32:00 +
From: mela...@t-data.com
To: opensim-dev@lists.berlios.de
Subject:
Not that I would champion it, but X3D should be mentioned, I guess.
Best regards,
Stefan Andersson
Tribal Media AB
Date: Mon, 23 Feb 2009 09:36:33 +0200
From: ant...@kyperjokki.fi
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] MXPClient?
Frisby, Adam kirjoitti:
Has anyone written a decent X3D adapter in C# ?
Adam
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan Andersson
Sent: Monday, 23 February 2009 1:18 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] MXPClient?
Not that I
Well the name changed came from because at first I was doing a different ICore
interface for each server. So had IGridCore, IUserCore, IMessagingCore (not all
committed to SVN). But then wanted a common core interface. And as IGridCore
gave the impression that it was for the Grid server, I went
i would suggest to recompile all the scripts after an update.
There is an option in the ini for that, something like compile on startup.
Maybe we could implement a console based command like recompile all ?
Sm
On Mon, Feb 23, 2009 at 9:54 AM, Frisby, Adam a...@deepthink.com.au wrote:
Sim
Typo Correction:
*Maybe a name change on that module is needed as well, so its clear its about
Messaging servers registering with it and
provides a inteface so other modules can request the data about those
registered messaging servers.
--- On Mon, 23/2/09, MW michaelwr...@yahoo.co.uk wrote:
I believe that rev 8581 fixes the annoying Solutions folder thingy for express
versions of visual studio.
As I don't have express myself, I can't test it, so please report back with
findings.
Best regards,
Stefan Andersson
Tribal Media AB
Ok, I'm trying a little bit of an experiment here and I'm wondering if
anyone else has tried this and had similar results? We're running ODE
on Linux Ubuntu using a vps setup hosted on quad core Xeons.
I'm going on the concept that if an object does not need any sort of
physical interaction
Really interesting John I will do a similar test, we are 100% Windows
Datacenter 2008 w Hyper-V so results should be similar
-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of John Sheridan
Sent: Monday, February
I guess your pulling out that code made the situation more explicit than
it was before :)
If that's the case, could we then think of separating the basic Map
service from any administrative grid services that people may want to
come up with for grids.
Running a grid a-la Linden Lab involves
Just as a completely theoretical question, how much work do you think would be
involved in pulling all LLUDP and Linden viewer-specific code out of OpenSim
and putting it in a module? It would be interesting to see an MXP-only OpenSim.
John
-Original Message-
From:
Phantom prims do not require a proxy, which is an in-memory representation
of the object used to compute collisions. Proxy memory usage is directly
related to prim complexity, and simple boxes and spheres are the most memory
efficient. Memory requirements increase as prims are reshaped and
Great explanation thanks Dahlia!
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Dahlia Trimble
Sent: Monday, February 23, 2009 1:39 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Phantom prims and memory usage?
Phantom
To have a generic service server is my eventual goal with the refactoring I
started on the User/Grid/Messaging server. Its going to be a while before we
get there.
But what I'm aiming to do is spilt the current User, Grid and Messaging servers
into modules, and a set of database access service
Hello
I got promising link from yesterday from Ryan (sempuki):
http://dev.aol.com/OpenidTokenExchange
That seems to be developed to solve exactly this problem. First point of
authentication fetches tokens from token exchange, passes those temporary
tokens to other components which use them to
Dear Diva:
As charles.kri...@osgrid.org, all I can say to all that is : Harumph.
And the fact that you bring up a number of good points. It is especially
thrilling to actually think we may have enough reliability to actually begin
thinking about implementing some of the needed security.
It is
I recently talked to mrtopf/tao takashi about getting openid into opensim
because I was/am hoping to sink a couple of developer days into implementing
this.
from what I understood one the tricky parts is to implement openid in the
client, since from an openid standpoint you dont want the
The license is LGPL, so I don't know exactly how that works. To avoid any
licensing issues, I release the following blurb of code that I designed and
wrote by myself to the public domain:
public interface ILogWriter
{
void Debug(object source, string message);
void Debug(object source,
As we cannot change the viewer at the moment one could use the opensim login
code to create the token...
regards,
Tommi
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
1) Well, we could change at least the hippo viewer *ducks*
2) 'one could use the opensim login code to create the token' so
the OpenSim instance simulates the viewer for now?
Von: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von
You could use the LLClientView to do it as well. So other protocols
(MXP) with their own client views could go directly to proper model.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Hi there,
Tokens is definitely the right technique to choose.
It does not adresse trust concerns against the token-provider (i.g. the
gridserver operator) and does not implement a fully trusted secure stack.
But its a major step towards the goal and a decision to choose the right
and most
Right. The constraint here, let's not forget, is that we want to
continue to reuse the LL viewer for a while.
I'm going to read that doc about OpenID tokens, but if it requires
participation from the viewer, forget it... We are and will continue to
be in LL Viewer hacking mode in the
I meant that in LLClientView login we could contact the open id token
provider for token. Each ugaim could basicly implement open id token
provider functionality as well in case all users are not interested to use
external token provider. This would enable us to use grid based user
directories as
Decided to go for slightly simplified solution and drag that log4net
dependency with MXP for now but allow other alternatives:
using System;
using System.Collections.Generic;
using System.Text;
using log4net.Repository.Hierarchy;
using log4net;
using System.Reflection;
namespace MXP.Util
Crista,
* The bottom line question in my email, phrased in OpenID terminology, is
whether we*
* can use **the Viewer's IP address as the token.
*
My question is, would you really want to use the Viewer's IP address as the
token? What IP address would it specifically use?
If a user were on an
Rephrasing my question again: not the token but as the unforgeable
basis of a token. The token will have more information like the port
and user's identifiers that we are already using. But all those can be
stolen. The sender's IP address cannot be stolen, I've been told.
OpenSim already gets
A RADIUS server is a solution to the problem of authentication. OpenID is a
solution for federated identity, and plays nicely with any authentication
solution you want to use. I think the description of this particular problem is
closer to identity verification across administrative domains
However, this would currently have to happen purely as communication
between backend services since we can't change the viewer.
This doesn't solve the man-in-the-middle problem in OSGrid itself, which
needs to be solved too, urgently.
I think my proposal does.
Crista
Hurliman, John wrote:
To be precise:
I think my proposal solves the problem of malicious agents in general,
for grids like OSGrid, Hypergrid, and all sorts of other configurations,
assuming this LL Viewer. However, since I'm not an expert in security,
I'm waiting for someone to prove me wrong.
This is not to say
Well, I suppose that since we can discern which viewer logs in via the
UserServer, we can allow additional features for some viewers that dont exist
for others.
Dont know if that simplifies or complicates the problem, however.
Charles
From: Diva Canto
A RADIUS server would make administration of user accounts, and also group
permissions much easier to administer. (Such as Grid Administrators, and
PeaceKeepers that are capable of ejecting obscene users or troublemakers
from the grid).
http://en.wikipedia.org/wiki/OpenID
OpenID could work hand
The only thing that concerns me about using the endpoint for
authentication, is it's UDP. Anyone with access to raw sockets your
IP address, UUID and circuit code, session ID, and SecureSessionId
could pretend to be you. I would suggest a better way to validate
the endpoint would be to verify
*The only thing that concerns me about using the endpoint for
authentication, is it's UDP. Anyone with access to raw sockets your
IP address, UUID and circuit code, session ID, and SecureSessionId
could pretend to be you. *
Wouldn't it be possible to validate the endpoint over SSL?
Why not
Just to clarify...
* Grids could provide openIDs in the form of **
openid.osgrid.org/users/screenname* http://openid.osgrid.net/screenname**
With all grids being independent of one another, or in the example given by
John, maybe use an openid.osgrid.org/users/screenname
Mark Malewski wrote:
Just to clarify...
*/ Grids could provide openIDs in the form of
/**/openid.osgrid.org/users/screenname/*
http://openid.osgrid.net/screenname*//*
With all grids being independent of one another, or in the example
given by John, maybe use an
Yes, with UDP that is easy to do (and has been used in multiple attacks against
SL). Just don't expect any of the response data, since it will be routed to the
correct owner of that IP endpoint.
John
-Original Message-
From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
Crista,
If Grid owners chose to use OpenID to allow users to authenticate (between
grids) that would be a choice that a Grid owner would have to make. You
can't just expect ALL grids to be wide open, without any form of
interoperable secure authentication (trust) between grids, and also expect
John,
I apologize. I didn't realize that OSgrid.org and uic.edu were both already
running OpenID identity servers. I believe Crista misunderstood what I was
saying (I admit my words were a bit unclear).
This is what I said:
* This way various grids could all run openID servers, and
42 matches
Mail list logo
