implementation proposal

I'll try to work out a rough implementation proposal here.

user node-type

Its necessary, that for every user automatically exists a node in the system. A module has to care for creating/deleting this node, whenever users are added/deleted - so other modules can rely on that a node exists for each user, if the module is activated.

two approaches came to my mind, they are only different in the content-type that is used for the automatically created usernodes:

• Approach A
  create a content-type, which doesn't contain any data except of the connected uid. prevent users/admin from manually adding/editing/deleting such a content-type.
• Approach B
  The module should create a user-CCK-content-type, which can't be deleted (without removing the module). So this content-type would naturally act similar to the core-profile-module. But are predefined node-types currently possible with cck?

I would prefer Approach B, but there is also a disadvantage:

• dependency on CCK

update:
I implemented approach A => the usernode.module.

usernode view

With the basic usernode-type it would be possible to classify the users using taxonomy, provide extended user listings and so on.
but which info, shall we display if a usernode is visited?
An idea, which came to my mind is to use this node-view as a kind of public user-profile in contrast to the normal user page, which can be used for display private information regarding only this user, e.g. present him his user-settings, as it would make sense, that modules still use hook_user() to offer their user-settings.

views

To make views on user possible, the usernode type shall advertise the user's data to the views module, similiar it already works with the userreference-cck-type.

node relations

Now, as there is a node for each user, we can just define further profiles with the help of the cck or custom-modules. Then, it would be great to have node-relations between all the node-profiles maintained automatically. So the user's public profile (the node profile) could be extended with role-dependend different node-types, optionally we also could allow a 1:n relationship.
update:
The nodefamily module allows all that, also n:n relatoins and isn't limited to profile nodes.

node relations & views

In my opinion it would be important, that the relations are recognized by the views module, so that it's possible to list all existing user information in a view. At least the 1:1 relations should work.
update:
This can be achieved with the views_fusion module :)

node-relations-api

An important point to investigate is wheter there already exists a node-relations-api, which would help implementing this.
There are some admin-controllabe ones, but as node-relations shall be maintained automatically, they shouldn't be changable by an admin.

-fago