<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
That is a possibility. However, it seems a bit more complicated than
necessary: you don't necessarily need to separate the concept of
"agent" from the concept of "avatar", a 1-to-1 relation between these
is fine. <br>
<br>
I'm imagining the interaction of what you propose: I (actual person)
sign up to the metaverse with one of many agent credentials, say my
verisign credentials; suppose I have another one at yahoo, for example,
or even a second one at verisign; then the viewer makes me choose
between my many online names of avatars associated with my first
verisign agent -- that's the step I think is unnecessary. Since I can
have many accounts anyway, I don't need many avatars per agent. --
although I can see what you are saying is inline with the prevalent
model of avatars being a grid concept, and therefore being able to
change as one goes around different grids with the same agent.<br>
<br>
In my view of things, users and agents, along with their credentials,
storage and comms, would be served outside of grids, and there would be
no *persistent* representation of them at the grid and regions server
levels -- although grids might choose to provide that
user/identity/agent service too, at least for some people. But this
service would be completely separate.<br>
<br>
I would like to sign up to the metaverse under one of my accounts and
be able to go around many grids. There will be grids that won't allow
my account there. That's fine. If I really want to go there, I should
get an account with that grid, or with whatever identity service it
accepts.<br>
<br>
What you're proposing is one step more generic than what I, personally,
need. More importantly, wearing my hat of a close advisor to
organizations who are interested in developing services in 3D, I think
that any persistent user/avatar representations at the grid level are a
burden for these organizations. They will want visits from millions of
people, and they don't want to store any information about those
avatars, other than logging their visits.<br>
<br>
The best way of envisioning what I'm saying is to place yourself in the
shoes of a university.<br>
<br>
Stefan Andersson wrote:
<blockquote cite="midBLU134-W367A60AECD1254F51E7F3AD5E90@phx.gbl"
type="cite">
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>Ehrm , not to spin off in too many directions at once, but we
really should acommodate for a somewhat more comprehensible set of
concepts:<br>
<br>
"User" : an actual acting person in the real world - <br>
* can have many Agents (consider same person running
-multiple viewers)<br>
* has a real name, and an online name<br>
* has a profile with profile data<br>
* has credentials, to be able to be authorized<br>
"Agent" : the informational representation of a user in a world<br>
* has credentials, to be able to be authorized<br>
"Avatar" : the visual representation of an agent in a world (only one
per Agent in the SL universe afaik)<br>
* has an online name<br>
* has a profile, with profile data<br>
"Credentials" : data supplied for authentication (user names, keys,
passwords, hashes, et c)<br>
<br>
One example:<br>
<br>
I'm Stefan Andersson in the real world. When I don't want to disclose
my full real name, such as in IM lists, I just call myself 'Stefan'
(which, in this case, is my chosen 'online name' or 'calling name').<br>
<br>
Now, in most user databases, I need a unique login credential, usually,
i choose the username 'lbsa71' since that's available more often than
'Stefan'.<br>
<br>
Now, of course, I have a couple of avatars in SL, one of them is called
"PierreJoseph Proudhon" (first/last construct by SL convention -
strictly not necessary)<br>
<br>
To choose what avatar I want to join SL with, and at the same time
authorize myself, I enter an avatar name and avatar password into the
viewer, which then uses it to authorize the agent with which I enter
the 3D world.<br>
<br>
My point here, is that although this is how SL works, it's not how
OpenSim ought to work. The same 'shortcuts' could be the default
implementation, but we really should be able to log in with one set of
credentials, which would not be tied to the avtar at all. Also, some
other viewers or launch methods might let the user log on with his user
credentials, and simply CHOOSE his avatar (the web page login method
would allow for such a scheme)<br>
<br>
I guess we might not even want to consider the 'user' and his
credentials, and leave that to various implmentations (like, how each
grid has their own user profile) but we should definitively call the
Avatars profile data 'AvatarProfile' - and separate "Agent login
credentials" from "Avatar online name".<br>
<br>
So; awaiting feedback, I propose we work towards the model outlined
above.<br>
<br>
Best,<br>
Stefan<br>
<br>
<br>
<br>
<hr id="stopSpelling">
<br>
> Date: Sat, 12 Apr 2008 08:00:22 -0400<br>
> From: <a class="moz-txt-link-abbreviated" href="mailto:sean@dague.net">sean@dague.net</a><br>
> To: <a class="moz-txt-link-abbreviated" href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
> Subject: Re: [Opensim-dev] Question on Avatar Appearance
persistance<br>
> <br>
> On Fri, Apr 11, 2008 at 06:09:56PM +0100, Michael Wright wrote:<br>
> > okay will try to make this my last email (before anyone
replies) on this. But I think I'm understanding more of what you meant.
<br>
> > <br>
> > And while I think there is no reason why we couldn't have<br>
> > AvatarAppearance hanging off UserProfile data. I'm still not
convinced<br>
> > there is a need to try to connect all these things. Avatar
Appearance<br>
> > is certainly a scene thing. In that every ScenePresence needs
a<br>
> > reference to one. But we could move the actual Av atar
Appearance<br>
> > class out to OpenSim.framework, or if going with the "Anemic
Domain<br>
> > Model" appoach suggested by Stefan then we could have a base<br>
> > AvatarAppearance in the model project. Then in the avatar
appearance<br>
> > module fetch the appearance object that was attached to the
user<br>
> > profile.<br>
> > <br>
> > But I'm not sure I really see any benefit in this over the
module<br>
> > doing a direct request to the user server for the appearance.
I<br>
> > actually think its better to decouple things in this way.<br>
> <br>
> By decoupling from the user server, we've coupled AppearanceModule
to<br>
> DataMapper, and are managing database connections in a
RegionModule,<br>
> which I think is a worse approach. <br>
> <br>
> m_scene.CommsManager.UserService.GetUserProfile(id) seems<br>
> like a much better approach. We could just add .GetUserAppearance
and<br>
> friends to it.<br>
> <br>
> > As I said in my last email, there could also be some
bots/NPC's that<br>
> > don't have userprofiles. And also I think there is a chance
that scene<br>
> > presences are created (and the appearance fetched) before the
user<br>
> > profiles are. But can't be sure of that without looking
deeper in the<br>
> > code.<br>
> <br>
> If an NPC exists in the environment, I would think it would have a<br>
> profile (it needs that for Name for instance).<br>
> <br>
> > But anyway as long as we went through the avatar appearance
factory<br>
> > module concept to fetch the appearance that was attached to
the user<br>
> > profile. Then I guess there is nothing stopping it. Just
seems a<br>
> > coupling that isn't needed.<br>
> <br>
> Yes, that's probably strictly true. Actually, we don't really need
it<br>
> hanging off of UserProfile. What I really meant was that<br>
> AvatarAppearance was an object that existed, and was
fetchable/updatable<br>
> from the UserService by UUID.<br>
> <br>
> > I am very strongly of the opinion that we need to keep the
factory<br>
> > module concept. So that a different module could be used.
Different<br>
> > regions/applications might want a completely different
approach to how<br>
> > the appearance of the avatars are handled. Like a game might
want to<br>
> > randomly just give each user one of a set of preset avatars.<br>
> > <br>
> > But with this factory module. We can actually fetch the
appearance<br>
> > from where ever we want, including the userprofile if it is
decided.<br>
> <br>
> If we move the default storage back into UserService, I don't think<br>
> we'll have an issue here. UserService will just support a
persistance<br>
> model for appearance, should anyone want to use that. How
appearance is<br>
> created remains in the region modules.<br>
> <br>
> -Sean<br>
> <br>
> -- <br>
> __________________________________________________________________<br>
> <br>
> Sean Dague Mid-Hudson Valley<br>
> sean at dague dot net Linux Users Group<br>
> <a class="moz-txt-link-freetext" href="http://dague.net">http://dague.net</a> <a class="moz-txt-link-freetext" href="http://mhvlug.org">http://mhvlug.org</a><br>
> <br>
> There is no silver bullet. Plus, werewolves make better neighbors<br>
> than zombies, and they tend to keep the vampire population down.<br>
> __________________________________________________________________<br>
<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>