In this new architecture, things are broken up into micro-units in a
very unixish way. Do one thing, and do it well.
If profile is wanted, a profile service and profile server are the
way to go, not bundling it with user services.
And, in the end, the profile module already is a profile service
Melanie wrote:
Currently, profile information is handled in part by the user server
and in part by the profiles module.
This data really has no business in the user server, because it is
Linden client specific, furthermore, it should not be split between
two services.
The profile informat
Currently, profile information is handled in part by the user server
and in part by the profiles module.
This data really has no business in the user server, because it is
Linden client specific, furthermore, it should not be split between
two services.
The profile information in the user server
Melanie wrote:
> Profile information has no place in this architecture and will be
> handled exclusively by the profiles module.
Please could you elaborate on this. Why will this be handled differently from
the other things being handled by
servers? What are the implications of doing it this
t; 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 2
t even string +
> pass would be better than the current.
> >
> >
> > Best regards,
> > Stefan Andersson
> >
> >
> >
> >
> >> Date: Mon, 22 Jun 2009 06:33:51 -0700
> >> From: lo...@ics.uci.edu
> >> To: opensim-dev@lists.
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: lo...@ics
un 2009 06:33:51 -0700
> From: lo...@ics.uci.edu
> To: opensim-dev@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 sh
+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 ou
That is outside the scope of OpenSim. It can be handled at the
database level.
Melanie
Sacha Magne wrote:
> One question :
> Will thoses servers allow duplication across physicals servers to allow
> some kind of redundancies , ie one or several servers crashs won't impact
> the grid ?
>
> Sac
One question :
Will thoses servers allow duplication across physicals servers to allow
some kind of redundancies , ie one or several servers crashs won't impact
the grid ?
Sacha
On Mon, Jun 22, 2009 at 1:38 PM, Melanie wrote:
> After breaking my head over this for a few weeks, I believe I hav
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 w
12 matches
Mail list logo
