Need Conventions for Activity Targets & Data

So I changed things again before the DRUPAL-5--3-0-BETA version. There is now a new table:
mysql> describe activity_targets;

+-------------+-------------+------+-----+---------+-------+
| Field       | Type        | Null | Key | Default | Extra |
+-------------+-------------+------+-----+---------+-------+
| aid         | int(11)     | NO   | PRI |         |       | 
| target_uid  | int(11)     | NO   | PRI |         |       | 
| target_role | varchar(50) | NO   | MUL |         |       | 
+-------------+-------------+------+-----+---------+-------+

aid is a fk to activity. target_uid is the person to whom the message should be visible (a $user->uid). Target role is a string defined in hook_activity_info by the implementing modules. Here's an example implementation:

function user_relationshipsactivity_activity_info() {
  $types = user_relationships_relationship_types_load();

  foreach ($types as $type) {
    $token_types[$type->name] = $type->name;
  }
  if (count($token_types) == 0) {
    drupal_set_message(t('There are no relationships defined. Please define some !user_relationships before configuring the activity messages.', array('!user_relationships' => l(t('user relationships'), 'admin/user/relationships'))));
  }
  return array(
    'ops' => array('requested' => t('Requested'), 'approved' => t('Approved'), 'denied' => t('Denied'), 'canceled' => t('Canceled'), 'deleted' => t('Deleted')),
    'types' => $token_types,
    'roles' => array(
      // This is what corresponds to ACTIVITY_ALL
      'all' => array(
        '#name' => t('All (approved relationships only)'),
        '#description' => t('The general public.'),
        '#default' => '[x-is-blah-of-y]',
      ),
// TODO: there should be a #defaults array instead and the keys could be
// the ops. So for every role there is #defaults with 'requested' => 'default message' etc.
      'requester' => array(
        '#name' => t('Requester'),
        '#description' => t('The person who initiated the relationship.'),
        '#default' => t('You have requested to be [relationship-plural] with [requestee]'),
      ),

      'requestee' => array(
        '#name' => t('Requestee'),
        '#description' => t('The person with whom a relationship has been requested or created.'),
        '#default' => t('[requester] has requested to be [relationship-plural] with you'),
      ),
    ),
  );
}

As you see the roles each have their own message templates. This means that an activity message knows the user and the user role, thus has a personalized message. I think this will meet the need you were trying to address with your patch.

1) Activities vs. Requests
You're talking about a distinction that only exists at the user_relationships or buddylist module level. The philosophy of the activity module is to let those modules deal with the distinction between a request and an activity. If you leave the field blank on admin/settings/admin, no message will get generated, so you as the administrator also have the power to decide whether a request should be shown or not.

2) Scope vs. Targets/Roles
Again, the roles are completely module specific. Privatemsg might define the 'sender' and 'recipient' roles and not the 'all' role. The 'all' is the only universal one because it is tied to the target user ACTIVITY_ALL. The important thing to keep in mind is that target_uid determines who sees the message, and target_role determines which message template shows it. Thus there is no use in defining or standardizing the roles as they only exist for the benefit of the implementing module.

3) Activity Recording & Display
I want to see an activitypreferences module that lets users decide which activity they see and what activity they have recorded. I've tried to make provisions for this in the base API. Also, for the admin, there is always the option of leaving the message template fields blank and thus not having messages for that combination.

4) Standards/Conventions for Data Field
The Facebook API is great and I want that level of flexibility. I don't know yet that the activity API can handle all of what Facebook does... I think we need some stronger language tools before we can reach that level. Again, though, I don't see much chance of standardizing, other than finding data that is available to all modules and putting that in the activity module's token support. The problem's with standardizing all come from the fact that any module can implement activity support (and that's good).

5.x unsupported