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


Ignore:
Timestamp:
09/22/12 07:21:33 (9 years ago)
Author:
Pat Tressel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Messaging/Outbound

    v17 v18  
    6666* Verify that there are no problems with (e.g.) orphaned entries if there are multiple accessors to the queues.
    6767
     68* 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.
     69
    6870Later:
    6971
     
    9799* Distribution list members, who may not be site users.
    98100
    99 Two main options for supporting addresses without associated pentities:
    100 * Add a bare address field to the outbound message queue elements.
    101 * Give the bare addresses a pentity, and a pr_contact entry.
     101Options for supporting addresses that don't have associated pentities:
     102* 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,...)
     103* Add a bare address field and a transport type field.
     104* 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.
     105* Give the bare address a pentity and a pr_contact entry.
    102106
    103 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.
     107The 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.
    104108
    105 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).
     109If 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.
    106110
    107 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?
     111The 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?