+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
