Something to keep in mind:
For the time being, we're talking about URLs that would likely GET
people's profiles -- that'd be the only time at which these global
identifiers would be invoked.
Again, HG authentication has nothing to do with this, it doesn't even
use these particular references.
On Aug 31, 2010, at 4:09 PM, Melanie wrote:
According to the tenets of REST, if you do need to retrieve data
that is constant, you use GET and caches may cache it.
If you want to initiate something, like a chat, you would use POST.
Caches are not eternal. So retrieval of profile info may be slightly
out of date (depending on cache ttl).
POSTed chat requests, etc, won't be cached, as POST replies are
uncacheable.
Melanie
Dahlia Trimble wrote:
OK, so if all the information needed is in the URL and the URL is
cache
friendly, what if whatever information the URL is supposed to
reference
changes upstream? How is it ever going to be retrieved? You've
already
designed a cache into the system with the format of the URL, at
what point
were you even considering making the request?
On Tue, Aug 31, 2010 at 3:13 PM, Melanie <[email protected]> wrote:
I'm not relying on one. I'm imagining a world where VW traffic is
the main part of internet traffic, having displaced the flatweb. For
ISP caching, it's important that most protocols are designed to be
RESTful. I don't plan on caching, but i don't want to create a
protocol that is inherently uncacheable. Be nice to the net.
Melanie
Dahlia Trimble wrote:
if you're relying on an external cache, why do you need to store
the same
information in the url?
On Tue, Aug 31, 2010 at 1:05 PM, Melanie <[email protected]>
wrote:
See my prior messages. That format is inherently un-cacheable. I
believe the mandatory info needs to be part of a URL that can be
fetched with GET and cached, e.g. is RESTful.
Melanie
Dahlia Trimble wrote:
I've tried to use extra information in URLs before by slash-
delimiting
them
and all seemed to work well until I ran into situations such as
missing
data
for one of the terms and some URL parsers did not accept the
double
slash
which resulted from the missing field. Another problem exists
when
extending
the definition at a later date, then all parsers that have to
deal
with
the
URL have to be modified. After banging my head over these kind if
issues
I
went back and redesigned it to use the &name=value format and
I''ve
never
regretted it since. Parsing it is quite simple in C# with
String.Split()
Given the open source nature of OpenSimulator, I would think
diverging
definitions would be unavoidable and would likely hinder
interoperability
unless some means for allowing flexibility was designed in from
the
start,
and I think name-value pairs are a usable means of providing that
flexibility.
On Tue, Aug 31, 2010 at 7:53 AM, <[email protected]> wrote:
Hurliman, John wrote:
It sounds like the decision has been made (or was already made
before
this
discussion started), so on to the next step. Can you (Melanie
or
Diva)
do
these two things?
As I said, the issue was *really* narrow :) Even though the
interfaces
already account for this, I got scared when I faced the
situation of
actually creating persistent references to external data. (or,
in the
case
of Simian, creating persistent data structures representing
external
data,
which is similar)
1) Define exactly how the URL is supposed to be parsed. ABNF
notation
would be preferred, or something equivalent that makes it
clear what
identifiers are valid or invalid. Or perhaps define any URL
as valid
like
diva suggested, but only parse display names out of
specifically
crafted
URLs. With the suggested format of
http://authority/user/user_id/First+Last it seems like you
would
either
assume any URL that includes a space in the last section of
the path
is
parsed as a first+last name tuple. (I'm assuming you remove any
attached
query string before parsing the name.) Or will it look for
"user_id"
as
the
second to last segment of the path followed by a path segment
containing a
space? Obviously it can't expect /user/user_id/First+Last to be
anchored at
the root of the domain since it won't be possible to generate
those
URLs on
some setups.
Yes, and that's the crux of the narrow issue in discussion. So
let's
finish
those little details on the IRC, maybe.
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.
John
-----Original Message-----
From: [email protected] [mailto:opensim-
dev-
[email protected]] On Behalf Of [email protected]
Sent: Monday, August 30, 2010 3:39 PM
To: [email protected]
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: [email protected] [mailto:opensim-dev-
[email protected]] On Behalf Of Melanie
Sent: Monday, August 30, 2010 2:30 PM
To: [email protected]
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, [email protected] 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
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
------------------------------------------------------------------------
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
------------------------------------------------------------------------
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
------------------------------------------------------------------------
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
