Yes, I'll take care of the no default appearance case.
Only the inventory service will touch inventory data. The service's existing AddFolder() and AddItem() calls will be
used to setup default inventory, rather than this being hardcoded within IInventoryService.CreateUserInventory(). An
AddFolderContent() could make this more efficient rather than making a call for every node.
As for co-ordination, if you look at UserAccountService.CreateUser() you'll see that this service is today co-ordinating
user creation. As well as creating the account, it sets the password on the authentication service, sets the home on
the grid user service, calls the inventory service, etc.
But I agree that a metaservice could do this co-ordination instead.
UserCreationService perhaps?
I'll take a look at Wifi and may well borrow some ideas or code.
On 29/01/11 01:54, Melanie wrote:
Please don't ignore the case where no default appearance is desired.
Also, the UserAccount service should not directly access the
inventory database. That would severely break the
compartmentalization ROBUST is built on.
The correct way is to have the inventory created by the inventory
module, as it is now.
The inventory module has no business populating that, and neither
does the account service. This should be done by an external
service, since it is only done on account creation.
A meta service, like the LLLoginService, which takes the interfaces
of both the inventory and avatar services and creates the inventory
AND appearance and stores it in both would be the correct solution
to this problem. It would be wrong (and get a -1) to shoehorn this
into the existing services.
ROBUST services are designed the Unix way. Do one thing, and do it
well. The inventory service is not meant to access appearance, the
user account service is not meant to access inventory, and so on.
Such a meta service can then be loaded by the user server, a
standalone or a web service like Wifi. And, obviously, it's
configurable, so people who don't want to have a default appearance
created, because they for instance have already working PHP code
that would be messed up by preexisting data could just not configure
it and see no change to current behavior.
Melanie
Justin Clark-Casey wrote:
Hi there,
Today, I had an opportunity to do some more work on setting up default
clothing/body parts for viewer 2 (this is in the
"viewer-2-initial-appearance" git branch).
I've come to the realization (obvious in retrospect) that giving these items
the default item IDs that the viewer wants
in the absence of any other appearance data is not going to work. This is for
the simple reason that item IDs are
primary keys and cannot be shared between avatars.
Therefore, I will need to use a random item ID and use this to set up a default
appearance at the same time as the
inventory items are created (currently, the appearance is only generated when
the avatar first logs in).
The user account service co-ordinates user account creation. It seems that the
sensible thing is to move default
inventory creation from the inventory service into the user account service.
Folder and item creation would take place
through existing add calls.
The IInventoryService.CreateUserInventory() method would still be called but
would only set up the very bare minimum
structure. In the SL case, this is just the user's root "My Inventory" folder.
The copy/pasted code for setting up estate managers in
Scene.SetModuleInterfaces() also has to move. The sensible thing
seems to be to expose a IUserAccountService.CreateUserAccount() call which is
only available to standalones (as is
effectively currently the case).
Commit 50254bf3 on this branch contains a rough version of this change. The
code to set up a default appearance with
random item IDs for default clothing/body parts has not yet been done.
Comments?
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
