On 31/08/10 15:53, d...@metaverseink.com wrote:
Hurliman, John wrote
2) Standardize the handling of external identities in OpenSim. Go
through and clean out the approaches that are no longer being used,
such as OpenSim.Framework.Communications.Osp. I can help with this
part as I'm always a fan of removing dead code.
That's the only broad consequence of this issue, and one that I also
feel it's very important. I know these global names have been used
before -- or maybe never used, but the code is there -- and, even though
I didn't remember the syntax, I remembered that it looked nothing like
an URI. Thanks, Justin, for explaining. If everyone is ok with the URI
syntax, then let's make it consistent across the board.
Parts of the OSP code will need to remain since they will always be required to load V0.1 IARs. I would also rather
keep the inventory plugin wrapping bits of now as I feel they could be a useful implementation pointer in the future.
However, the code could be moved to the IAR module since it won't be generally used in the future.
If you're looking to cleanup dead code, I suggest that you look at things such as the stub Sirikata client plugin and
the SVN and Content Management System modules. No offense to the creators, but some of these have never progressed
beyond stubs and are clutter. The two modules still compile but I wouldn't be surprised if they don't work any longer
due to bit rot. The fact that they haven't been maintained means that they're good candidates for removal unless
someone wants to support them.
John
-----Original Message-----
From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
Sent: Monday, August 30, 2010 3:39 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Global identifiers
OK, so here's the form of the URI that will start showing up in the
[non-Simian] DBs soon, specifically in the GridUser table:
http://authority/user/user_id/First+Last
Yes?
I suspect that SimianGrid will take things like
LoggedIn(string userID) and
StoreGridUserInfo(GridUserInfo info)
and create user accounts for these if they don't exist, because I think
SimanGrid collapses the 2 concepts. Just keep in mind that you'll soon
be receiving URLs of the form above as arguments.
I agree with Melanie that not adding the display name is a missed
opportunity for caching, but I'm willing to write up code that accounts
for it being optional for all the grid operators who would rather have
the extra lookups coming their way.
Hurliman, John wrote:
If we are still on the same page, there should never be a case where
something could be either a local identifier (UUID) or a global
identifier (URL). The context is always clear, where cross-grid
communication and exported content uses only global identifiers and all
intra-grid communication uses only local identifiers. If a sim wants to
resolve the creator of a prim it uses a single path, the UUID->Profile
(aka display name) API call which takes advantage of all the caching
and optimizations we've built into OpenSim. There is no ambiguity there
or potential for the code to take a slower or less tested path. The
discussion is about communication outside of the local grid context,
when you are exporting content or moving people or content between
grids. In every use case there I think it makes sense to always use
global identifiers, or at least a clear path to build a global
identifier.
John
-----Original Message-----
From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
boun...@lists.berlios.de] On Behalf Of Melanie
Sent: Monday, August 30, 2010 2:30 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Global identifiers
I think we already have a perfectly good field, which is a UUID for
local users and a URL for remote ones.
Melanie
Serendipity Seraph wrote:
On 8/30/10 2:09 PM, d...@metaverseink.com wrote:
Hurliman, John wrote:
My interpretation (please correct me if I'm wrong) is that there
is
rough consensus on the overall strategy, but an open question of
how
to encode global identities when cross-grid communication (or
out-of-grid archiving) happens.
That's what's going on.
Up to now, all global identifiers (that already exist) have been
volatile; nothing has persisted. As I found myself writing code
that
would inject global identifiers into a DB table, I thought we
should
all talk about the form of such identifiers.
There is probably also a hidden question of how to mark a local
account as linked to a foreign identity, which may solve the
friending issue. If I am friends with your avatar and we are both
on
grid B but your avatar actually originated from grid A, that link
in
the profile is what can tip off the presence service to try a
remote
presence check (assuming the user is not online in the local
grid).
My only interest in these low level questions like how the global
identifiers and profile links look is what the final decision is
so
I
can implement it in the OpenSim SimianGrid connectors.
Well, we distinguish "user accounts" from "grid users" -- these
are
2
different interfaces, although implementers may decide to collapse
them. But they are different concepts. User accounts are the
locally-registered users; in some cases, like for example, the UCI
grid, there's only some people who can get accounts there, namely
people associated with the university. Grid users are users that
are
referenced by things that happen in the grid. So we already have
an
interface for that, although now I'm thinking that perhaps we need
to
separate its UserID field into 2 things: a local UUID and a
reference
to the external name. And I guess that's my main issue at this
point.
It seems more reasonable in a distributed system to say that an X
is
an
X - a User is a User, whether they originally were instantiated on
a
local or a remote system. So I would go for collapsing the two as
much
as possible as a matter of policy. Otherwise freedom to move
between
nodes in the system is more limited and there is more special case
logic
to deal with. But that is speaking from a general distributed
computing perspective. There may be many Opensim details that make
that
seemingly ideal position in practice rather naive.
- s
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
