Sounds good. How about separating the friend management as well. Did you plan to include it in User Server?<br><br>- Antti<br><br><div class="gmail_quote">2009/6/22 Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Actually, Stefan, that has already happened :)<br>
<font color="#888888"><br>
Melanie<br>
</font><div><div></div><div class="h5"><br>
Stefan Andersson wrote:<br>
> 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.<br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> Everything else should be on other (protected) ports.<br>
><br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> 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.<br>

><br>
><br>
> Best regards,<br>
> Stefan Andersson<br>
><br>
><br>
><br>
><br>
>> Date: Mon, 22 Jun 2009 06:33:51 -0700<br>
>> From: <a href="mailto:lopes@ics.uci.edu">lopes@ics.uci.edu</a><br>
>> To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
>> Subject: Re: [Opensim-dev] Shaping the user services<br>
>><br>
>> +1 on this, especially separating the login functionality from<br>
>> everything else.<br>
>><br>
>> (I'll be back working on opensim shortly; I've been traveling and had<br>
>> some technical difficulties at the destination)<br>
>><br>
>> Melanie wrote:<br>
>> > After breaking my head over this for a few weeks, I believe I have<br>
>> > figured out how to do this in a sane way.<br>
>> ><br>
>> > The fallacy was to assume that the login server and the user server<br>
>> > would be one entity. That makes things overcomplicated and breaks<br>
>> > the architecture all over the place.<br>
>> ><br>
>> > Now, here is what I have come up with:<br>
>> ><br>
>> > User Server:<br>
>> > - Resolve name to key queries<br>
>> > - Resolve key to name queries<br>
>> > - Provide avatar picker lists<br>
>> > - Manage home region data<br>
>> ><br>
>> > Authentication server<br>
>> > - Create and manage authentication handles (string) and session keys<br>
>> > (UUID)<br>
>> > - Check passwords or other forms of authentication<br>
>> ><br>
>> > Login server<br>
>> > - Provide the interface for the Linden viewer to log into a grid.<br>
>> > Uses the services above, but doesn't contain them.<br>
>> ><br>
>> > Presence server<br>
>> > - Manages last position data<br>
>> > - Keeps list of logged in avatars and their locations<br>
>> ><br>
>> > Alongside with this, a new database is needed. This will not be an<br>
>> > upgrade path, but a parallel development with a migration tool.<br>
>> ><br>
>> > Profile information has no place in this architecture and will be<br>
>> > handled exclusively by the profiles module.<br>
>> ><br>
>> > The user table will specifically be designed to accommodate<br>
>> > additional fields and allow getting/setting of such fields.<br>
>> ><br>
>> > With all user data, a scope identifier will be passed. This will be<br>
>> > UUID.Zero in the most common case (Standalone or single grid) but<br>
>> > will allow sharing of server processes between multiple logical grids.<br>
>> ><br>
>> > Comments are welcome.<br>
>> ><br>
>> > Melanie<br>
>> > _______________________________________________<br>
>> > Opensim-dev mailing list<br>
>> > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>> ><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
><br>
><br>
</div></div>> ------------------------------------------------------------------------<br>
<div><div></div><div class="h5">><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br>