[consulting] the Ultimate forum based Malinglist Manager

Ryan Grace ryan at realenergy.net
Fri Dec 30 07:50:38 UTC 2005


Remember: ANYTHING is possible...
   i am thinking that giving organic groups a helper module or feature 
like massmailer for mailinglists which allows for different "engines" so 
that there can be a helper module which connects to mailman, another for 
ezmlm, sympa or whatever..
  there would also as the default be a basic mailing list built in..  to 
drupal.. yes.. that is alot of coding but that didnt stop them at 
groupserver.org...
  there has to be a way to have a php based mailing list that will run 
in a jailshelled shared hosting account... phplist is halfway there...
  moodle has it by default ???? is that true?(hard to read their site)
  this way, the yahoo group style functionality of subscribe, 
unsubscribe, digest.. list only, public/private is handled all within 
organic groups... the helper module does the mailing list integration, 
creation, deletion, syncing...
  I think mailhandler and listhandler can be put to use.. they just need 
to be automated within og...

it CAN be done!
thanks for reading,
ryan
thefractal.org
 

Dan Robinson wrote:

>>>Your point is well taken - but the idea of having "established
>>>standards" seems like a showstopper.  Also what you will wind up with
>>>are some tools you can use to write some more code.  My personal opinion
>>>is that there are no silver bullets here at all - just a lot of
>>>choices.
>>>   
>>>
>>>      
>>>
>>Based on Ber's opening statements, my impression was just the opposite.
>> 
>>
>>    
>>
>If I understand Ber correctly he is proposing a sprint to write some
>code  - I assume that this code will actually do something - in other
>words not just be a set of tools or APIs - if that is the case then this
>effort will have to take a particular path which will effectively make a
>bunch of very static decisions regarding the implementation.  I am
>saying that your call for interoperable standards is a showstopper -
>this is a case where you would be writing a standards based set of APIs
>or tools that would have NO implementation options.  In this case - IMHO
>- there is very little or no advantage to pursuing a "standards" strategy.
>
>  
>
>> 
>>
>>    
>>
>>>We'll pursue a MLM specific solution (ezmlm)
>>>   
>>>
>>>      
>>>
>>See, already there is splintering.  You are persuing ezmlm and CivicSpace is 
>>persuing Sympa.
>> 
>>
>>    
>>
>err.... Are you sure?  I think they just played around with Sympa - I
>don't believe they are doing anything more with it.
>
>  
>
>> 
>>
>>    
>>
>>>and leave open  
>>>the possibility of integrating other MLM's (or Drupal code) - however
>>>there will be no guarantee that another MLM will be adaptable to the
>>>code - because it may not have an adaptable interface (for example I
>>>have no idea if Mailman will be able to easily "slot into" the
>>>solution).
>>>   
>>>
>>>      
>>>
>>And this is the one I'm interested in.
>> 
>>
>>    
>>
>Right - so what do you want that will work with Mailman?  If I remember
>correctly Mailman (written in python) has an API and a DB structure -
>however it is doubtful that a hosting provider will allow you access to
>this.
>
>  
>
>> 
>>
>>    
>>
>>>So what do you propose to actually produce? 
>>>   
>>>
>>>      
>>>
>>Actually, I'm not really sure.  I was under the impression that this was the 
>>beginnings of the ground work and that no specific implementations were being 
>>discussed (except for the fact that there are some who are already persuing 
>>it on their own).
>> 
>>
>>    
>>
>The issue is - imho - that there *is no way* to come up with a really
>general solution to this problem.
>
>  
>
>> 
>>
>>    
>>
>>>What "standards 
>>>compliant" software are you referring to?
>>>   
>>>
>>>      
>>>
>>Mostly, I'm referring to RFCs.  While I realize there aren't a lot for 
>>governing MLMs, there are some.
>> 
>>
>>    
>>
>My limited understanding of the RFCs are that they cover behavior of the
>MLM wrt mail headers and possibly responses - I looked once long ago.  
>They don't go anywhere near defining the behavior etc.  As far as I know
>there are no *standards* nor anyway to come up with a one-size-fits-all
>solution.
>_______________________________________________
>consulting mailing list
>consulting at drupal.org
>http://lists.drupal.org/mailman/listinfo/consulting
>
>
>
>  
>



More information about the consulting mailing list