[consulting] the Ultimate forum based Malinglist Manager

[Gerhard Killesreiter]

Allie Micka wrote:

>
> On Dec 30, 2005, at 4:02 PM, David Geilhufe wrote:
>
>> As folks who were in early CiviMail discussion know, list handling  
>> is (was?) on our future roadmap.
>>
>> As you guys build a solution(s), please try to imagine how CiviCRM  
>> might be able to handle list member management via our groups  
>> functionality (subscribe/unsubscribe, write pointers back to their  
>> posts through activities, etc.).
>>
>> And when anyone is ready to work on that functionality, we'd be  
>> interested in seeing how we can contribute.
>
>
> CiviCRM/CiviMail solves a slightly different problem than the one I'm  
> discussing.  The MLM-backed solution I described is ideal for lists  
> that do not require any message customization.  This includes forum/ 
> og remailing and "big dumb announcement drops".
>
> I don't think that either my proposal or Gerhard's directly addresses  
> clickthru tracking or token replacement.  Mine definitely doesn't,  
> because the cases I've described are based on handing 1 copy of a  
> message to a MLM for re-distribution.
>

I am basically handling the same use case. Tracking or token replacement 
weren't listed as requirements. We are basically looking for an enhanced 
mailhandler/listhandler solution.

> Gerhard's queue/de-queue proposal has a chance at being "smarter", as  
> each copy of a message can be manipulated.  I haven't seen a clear  
> enough description of the mailqueue proposal to understand how it  
> would work:  You would either have to put a lot of logic into your  
> dequeuing script to handle token replacement on some kind of join; or  
> you would have to queue thousands of instances of a message when you  
> create it, and then turn around and de-queue them all.  If you went  
> the latter route, you'd induce the same timeouts that hamper existing  
> strategies.  Gerhard, can you clarify?


I have no intention to do any mail modifications beyond putting in the 
mail address.
We are basically looking for a yahoo groups replacement.

> I'll reiterate my point that list membership should be independent  
> from Drupal, because there's not necessarily a 1:1 relationship  
> between a mailing and a Drupal site.


In our use case there is this 1:1 relationship.

>   CiviMail is ideally suited for  this work, because that's how 
> CiviCRM is already architected.
>
> Drupal is unlikely to have the information it needs for token  
> replacement in a consistent format (first name, last name, address,  
> and so-on).  Again, this makes CiviMail ideally suited for "smart  
> mailings".
>

Token replacement is a typical feature for a newsletter script. What we 
will be developing isn't intended for newsletters, but for "real" mail, 
ie a two way communication.

Cheers,
    Gerhard