[Refactoring] Begin to split algorithm and datastructure

[Geod24]

I'd like to make 'User' and 'Groups' configurable entities. Currently they are really web-oriented, as is the controller. The REST interface doesn't need any activationCode for example ;)
So this first refactoring doesn't break anything, but starts to move thing to the web package.

On the long run, I'd like to:

• Make the controller the bare minimal for DB / user / group / auth interaction;
• Build more powerfull and feature-rich controllers on top of that (current db.controller would become web.controller. Maybe introduce a rest.controller.
• Make Group depends on User, not the other way around.

Prerequisites for #7

[s-ludwig]

Hum. The current User and Group structs are database oriented (at least that's the intention). Layering the database on top of web definitions would be wrong. The same goes for UserManController - it is just an abstraction over the DB implementation, nothing to do with web or REST stuff. web.controller would basically be UserManWebInterface AFAICS.

The reason that User has a list of Groups instead of the other way around is because there are usually few groups per user, but many users per group. This way, a User object can simply be stored as a single document in the database, while a Group object with a User list would quickly get too large.

We could of course completely decompose it, so that neither User nor Group has a list of anything and there will just be controller functions à la getGroups(User.ID) or getUsers(Group.ID). But that would mean that for example the MongoUserManController would either have to use a less efficient data representation, or duplicate the definition of User to add back the groups field privately.

[Geod24]

Hum. The current User and Group structs are database oriented (at least that's the intention). Layering the database on top of web definitions would be wrong. The same goes for UserManController - it is just an abstraction over the DB implementation, nothing to do with web or REST stuff. web.controller would basically be UserManWebInterface AFAICS.

Oh I see now, I had it the other way around. I would then recommend that the User definition should just be the ID + properties. Actually, the same is true for Groups. Does that make sense ?

For the same reason, the controller isn't independant from the web part ATM. Things like inviteUser, activateUser & co don't have much sense for the most basic REST interface. That's why I wanted to make the core handle only a small subset of operation - creation and deletion are the most basic ones -, and add the most common use case in userman.web and userman.rest.

[Geod24]

Closing this, I'll try to find a better approach.