Groups

I'm working on subgroups module. I want to maximize compatibilities with other modules, so I'm basing it on organic groups, though I think there are some key differences in application: The "view" page of an organic group node shows other nodes and a welcome message. I define a "group" to mean a set of people and subgroups (possibly with "role" text assigned to each), so by this definition the "view" of a group shows the tree that defines the group. Similarly, "edit" allows one to add and remove users

I'd like organic groups to be used to define access control lists to various data and actions throughout a drupal site. I'd also like web services on sites that aren't hosting a given group to have some access to group definitions. This might require OpenIDs for members, URLs that represent groups, and sharing an XML roster of a group at that URL for other sites to use - possibly restricted somehow in some cases. This should probably be a separate module from the subgroups module, but play well with groups and subgroups.

The real-life groups for which I'm inspired to code have members who I'd like listed, but who won't be users of the site immediately, or possibly ever. Therefore, a "missing users" feature set is important. This should probably be a separate module from organic groups and organic subgroups, but it should play well with them, as invite codes for missing users to assume an identity should only be generated by appropriate existing users.

I like that mailing lists are tied to forums in og2list, but I don't like that ogs are tied to forums. I'd like to use (dedicated) groups (with appropriate subgroups) to define who's allowed to web-view, RSS, web-post, subscribe, and email-post to a list/forum, but to have list/forum existence be distinct from a groups otherwise. This goes against the current structure of og2list, though, and therefore I'm not sure how compatible an idea it is. I'd either like to get involved in og2list with this in mind, or else build a somewhat redundant module.

So far, I've thrown together a module which has the "view" feature described in the first paragraph above. Subgroups still needs to be edited using the admin taxonomy tools, so I have to build the edit feature still. Shouldn't be too hard. Are there philosophical reasons why it's bad for me to be overriding load order to change what the "view" page has for a group node?

I also think CSS+Javascript should be used to control expansion within the tree view without requiring a page reload. I've coded such things elsewhere, but I haven't seen much functionality like that in Drupal, and I'm curious if there are philosophical reasons why I should not implement that GUI feature.