Changes between Version 17 and Version 18 of BluePrint/Messaging/Outbound

Timestamp:

09/22/12 07:21:33 (12 years ago)

Author:

Pat Tressel

Comment:

--

BluePrint/Messaging/Outbound

@@ -66 +66 @@
 * Verify that there are no problems with (e.g.) orphaned entries if there are multiple accessors to the queues.
 
+* Allow sending to bare addresses without pentities. For now, add two fields to the queue entry: address text and transport type. See below for discussion.
+
 Later:
 
@@ -97 +99 @@
 * Distribution list members, who may not be site users.
 
-Two main options for supporting addresses without associated pentities:
-* Add a bare address field to the outbound message queue elements.
-* Give the bare addresses a pentity, and a pr_contact entry.
+Options for supporting addresses that don't have associated pentities:
+* Add a bare address field to the outbound message queue elements. Either support only email, or encode the transport into the address, e.g. via an IANA scheme (mailto, sms,...)
+* Add a bare address field and a transport type field.
+* Create a pr_contact record for the address -- the contact record would hold the address and transport type -- and add a reference to the contact in the queue element.
+* Give the bare address a pentity and a pr_contact entry.
 
-The give-it-a-pentity-and-contact option is appealing because it allows any form of address, not just email. It also avoids (to some extent) the need to modify queue processing. For registration, one might hand this pentity over to the temporary user on successful completion of registration...or just get rid of it when the user completes registration and receives their "real" pentity.
+The avoids (to some extent) the need to modify queue processing. For registration, one might hand this pentity over to the temporary user on successful completion of registration...or just get rid of it when the user completes registration and receives their "real" pentity.
 
-For a bare address field in the queue entry, if we want to allow other than email, we'd need to specify the type somehow (e.g. by including the IANA scheme in the address or also adding a type field).
+If we include an explicit transport type field, either in the queue entry or in a contact, we don't have to attempt to infer the transport from the form of the address, nor include a scheme.
 
-The approver is awkward for assigning a pentity. We shouldn't ask the site to create a user for their approver and then enter the pe_id in their config file. It's mainly awkward because we don't have web setup. Once we have web setup, we'll have to deal with saving site config info somewhere -- file or database or... -- so saving the pe_id of the approver won't be different from saving the key for any other selected configuration item that's a record in the database. There's an additional awkwardness in that the site will have to add the approver as a user before they can configure them as the approver, so they'll have to get that user in before they can start registering other users normally. Is this case sufficient to derail the option of giving bare addresses pentities and contact records?
+The approver is awkward for assigning a pentity. We don't anticipate using anything but email for this. We shouldn't ask the site to create a user for their approver and then enter the pe_id in their config file. It's mainly awkward because we don't have web setup. Once we have web setup, we'll have to deal with saving site config info somewhere -- file or database or... -- so saving the pe_id of the approver won't be different from saving the key for any other selected configuration item that's a record in the database. There's an additional awkwardness in that the site will have to add the approver as a user before they can configure them as the approver, so they'll have to get that user in before they can start registering other users normally. Is this case sufficient to derail the option of giving bare addresses pentities and contact records?