[Opensim-dev] Splitting IUserService
Ryan McDougall
sempuki1 at gmail.com
Thu Jul 3 08:54:30 UTC 2008
I'm still not clear on all the architecture of it, but there appears to
be some cruft that could be cleared up and make my job easier depending
on where you intend to make changes.
What do you think you would be touching? If its just interfaces, it
might be a touch awkward, but relatively easy to work around.
But if you intend to reorganize internal structure, I think it could
only help me...
Cheers,
On Thu, 2008-07-03 at 09:36 +0100, Michael Wright wrote:
> Well my initial focus was more from the region side, so that we could
> have it using a different server if someone wanted (like we do for our
> apps). But yeah I guess server side the db handling should/could be
> separated.
>
> Although I think we most likely should hold of until Ryan has finished
> his plugin changes, else whatever is done would need changing once
> that is done.
>
> liu xiaolu <lulurun at gmail.com> wrote:
> Then should we add "IAvatarData" ?
>
> 2008/6/28 Michael Wright <michaelwri22 at yahoo.co.uk>:
> Does anyone have any objections to splitting the
> IUserService interface, so that the Avatar Appearance
> and attachments are in their own interface
> IAvatarService ?
>
> I really don't think we should be coupling things like
> we are. I'm not saying that these functions have to
> move off the User Server. Just on the region side, we
> move them into their own interface, so that if someone
> wants those functions to be on a different server,
> they can change the url of the server to be different
> to the user server with minor code changes.
>
> When I think about the various Servers, I generally
> think of the User server as holding account
> infomation. The Grid Server as being the general
> manager of the "grid". And the Inventory and Asset
> servers as the general datastores.
>
> So to fit in with my view, the avatar appearance data
> would fit better on the Inventory server or even a
> separate server that was part of the datastore group.
> This is so that we could have one central User Server,
> but a number of Inventory and Asset servers. Each
> user's in-world data could be on a different set of
> those.
>
> As I've said before, I really think we should have a
> system that allows the various backend functions to be
> where ever a grid admin thinks is best. But thats
> still a dream.
>
> But we can do a small change that would allow a
> different url to be set for the Avatar services, if a
> application required it.
>
> So what I'm suggesting is we add a new interface to
> the CommunicationsManager, like:
>
> public Interface IAvatarService
> {
> AvatarAppearance GetUserAppearance(LLUUID
> user);
>
> void UpdateUserAppearance(LLUUID user,
> AvatarAppearance appearance);
>
> void AddAttachment(LLUUID user, LLUUID
> attach);
>
> void RemoveAttachment(LLUUID user, LLUUID
> attach);
>
> List<LLUUID> GetAttachments(LLUUID user);
> }
>
> The OSGrid implementation could be exactly like it is
> now, and send the requests to the user server. I'm not
> even talking about adding a new setting to the ini
> file, but just leaving the code so it uses the
> UserServer url.
>
> So its really a minor change, but does decouple these
> functions from the more general user account
> functions.
>
>
> ______________________________________________________
> Not happy with your email address?
> Get the one you really want - millions of new email
> addresses available now at Yahoo!
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> --
> Lulurun _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> ______________________________________________________________________
> Not happy with your email address?
> Get the one you really want - millions of new email addresses
> available now at Yahoo!
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
More information about the Opensim-dev
mailing list