[Opensim-dev] Shaping the user services

[Melanie]

Friends is already separate. It has a presence server (the former 
message server) but it will be untangled. The user server no longer 
plays a role in presence management.

Melanie

Antti Kokko wrote:
> Sounds good. How about separating the friend management as well. Did you
> plan to include it in User Server?
> 
> - Antti
> 
> 2009/6/22 Melanie <melanie at t-data.com>
> 
>> Actually, Stefan, that has already happened :)
>>
>> Melanie
>>
>> Stefan Andersson wrote:
>> > Separating login from user service has been one of my concerns for quite
>> some time; doing so allow closed grids to expose only the login service
>> while keeping all other interfaces behind the firewall.
>> >
>> >
>> > I would argue that there should be exactly one grid services http port
>> that has to be opened in the firewall; the one that answers the login xmlrpc
>> (and llsd) request.
>> >
>> >
>> >
>> > Everything else should be on other (protected) ports.
>> >
>> >
>> >
>> > Pushing profiles out is also a big +1 for me, as I'm mainly concerned
>> with being able to take that information form other backends.
>> >
>> >
>> >
>> > While we're at it, could we please make the authentication token
>> pluggable, or at least something a little bit less SL-centric than first,
>> last, pass? pluggable credentials class would be best, but even string +
>> pass would be better than the current.
>> >
>> >
>> > Best regards,
>> > Stefan Andersson
>> >
>> >
>> >
>> >
>> >> Date: Mon, 22 Jun 2009 06:33:51 -0700
>> >> From: lopes at ics.uci.edu
>> >> To: opensim-dev at lists.berlios.de
>> >> Subject: Re: [Opensim-dev] Shaping the user services
>> >>
>> >> +1 on this, especially separating the login functionality from
>> >> everything else.
>> >>
>> >> (I'll be back working on opensim shortly; I've been traveling and had
>> >> some technical difficulties at the destination)
>> >>
>> >> Melanie wrote:
>> >> > After breaking my head over this for a few weeks, I believe I have
>> >> > figured out how to do this in a sane way.
>> >> >
>> >> > The fallacy was to assume that the login server and the user server
>> >> > would be one entity. That makes things overcomplicated and breaks
>> >> > the architecture all over the place.
>> >> >
>> >> > Now, here is what I have come up with:
>> >> >
>> >> > User Server:
>> >> > - Resolve name to key queries
>> >> > - Resolve key to name queries
>> >> > - Provide avatar picker lists
>> >> > - Manage home region data
>> >> >
>> >> > Authentication server
>> >> > - Create and manage authentication handles (string) and session keys
>> >> > (UUID)
>> >> > - Check passwords or other forms of authentication
>> >> >
>> >> > Login server
>> >> > - Provide the interface for the Linden viewer to log into a grid.
>> >> > Uses the services above, but doesn't contain them.
>> >> >
>> >> > Presence server
>> >> > - Manages last position data
>> >> > - Keeps list of logged in avatars and their locations
>> >> >
>> >> > Alongside with this, a new database is needed. This will not be an
>> >> > upgrade path, but a parallel development with a migration tool.
>> >> >
>> >> > Profile information has no place in this architecture and will be
>> >> > handled exclusively by the profiles module.
>> >> >
>> >> > The user table will specifically be designed to accommodate
>> >> > additional fields and allow getting/setting of such fields.
>> >> >
>> >> > With all user data, a scope identifier will be passed. This will be
>> >> > UUID.Zero in the most common case (Standalone or single grid) but
>> >> > will allow sharing of server processes between multiple logical grids.
>> >> >
>> >> > Comments are welcome.
>> >> >
>> >> > Melanie
>> >> > _______________________________________________
>> >> > Opensim-dev mailing list
>> >> > Opensim-dev at lists.berlios.de
>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >> >
>> >> _______________________________________________
>> >> Opensim-dev mailing list
>> >> Opensim-dev at lists.berlios.de
>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > Opensim-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev