some more stuff in rbac files...still nothing really useful, but finally I have more or less an idea how to implement it

include/permission.h

@@ -28,13 +28,29 @@
 #include "class.h"
 #include "storage/storage.h"
 
+/**
+ * These might be hardcoded within the application.
+ * In fact, as we are creating a restful CRUD application we might
+ * consider not having these at all but define that each resource
+ * might potentially have either Create, Read, Update and Delete
+ * actions.
+ *
+ * Suggestion Actions as Bitmask...
+ */
+typedef enum e_ResourceActions {
+	CREATE = 1,
+	READ   = 2,
+	UPDATE = 4,
+	DELETE = 8
+} ResourceAction;
+
 
 CLASS(Permission) {
-	char            id[37];
-	unsigned long   hash;
+	char             id[37];
+	unsigned long    hash;
 
-	char          * resource;
-	int             action;
+	char           * resource;
+	ResourceAction   action;
 };
 
 #endif // __PERMISSION_H__

include/role.h

@@ -41,9 +41,60 @@ CLASS(Role) {
 	 * \todo We need a good way to serialize a hash.
 	 * If I can't find any I should choose a different
 	 * data structure here...but I think there is a way.
+	 * And as there is none I will change this to simple
+	 * arrays and add an index to them that is a hash.
+	 * The arrays could even be static.
+	 * When a role is load the index on permissions and
+	 * users is updated each time.
+	 * The longer I think about it the less I think this
+	 * role based approach is good...
+	 * Each user is able to create resources (tasks,
+	 * projects, etc.) but in the first place these should
+	 * only be accessible for her/him. Then he should be
+	 * able to allow other users or groups of users to
+	 * access these but with each of these separately.
+	 * So at least this can't be accomplished only with
+	 * roles or else a role has to be created for every
+	 * resource.
+	 * OK, lets think about some roles:
+	 * - owner (for each resorce ... this will enable us
+	 *          to share ownership.)
+	 * - viewer (for each resource ... these might only 
+	 *           see the resource.)
+	 * - projectmember (for each project resource)
+	 * - teamlead (might have special rights for some projects
+	 *             and be able to see what each projectmember
+	 *             can see)
+	 * - projectowner (well ... this might be owner of
+	 *                 a project resource)
+	 * - projectadmin (being able to change parts of the project
+	 *                 but can't see everything...)
+	 *
+	 * I think I do not need an index here...because these are only
+	 * used to setup a permission set within the user session...so
+	 * these are simply added to this set.....
+	 * With the users it is a different story...in fact i don't think
+	 * that this relation should be stored here...this is an extra
+	 * relation which is indexed by the usr name and credential and
+	 * holds an array of roles he is in...on the other hand...if
+	 * a role changes we need a fast way to get all users to update
+	 * their permissions if they are online...
+	 *
+	 * New thoughts, a resource might be either a URL or a userid.
+	 * When it is a userid the configured rights are valid for all
+	 * resources owned by that user.
+	 * Each grouped resource has less precedence than a specific
+	 * one. That means, access rights can be removed for single
+	 * resources after they have been added via a grouped resource.
+	 * By default each user is assigned a role that allows him to
+	 * do everything with every resource she/he has created.
+	 * This role is also named after the user id.
 	 */
-	Hash            permissions;
-	Hash            users;
+	Permission * permissions;
+	size_t       npermissions;
+
+	User          * users;
+	Hash            users_idx;
 };
 
 #endif // __ROLE_H__