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 <[email protected]> > >> 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: [email protected] >> >> To: [email protected] >> >> 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 >> >> > [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
