[consulting] the Ultimate forum based Malinglist Manager

[Dan Robinson]

> Remember: ANYTHING is possible...

yes, agreed.  I'm not saying that you can't *abstract* out functionality
and make something that is usefull in a variety of situations.  However
in my opinion this space is particularly squirrley and doesn't lend
itself to easy answers.

>   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..

Right - but you might want to start enumerating what that helper module
needs to be responsible for - the list is quite large.  It is my
understanding that this is the path that Gerhard/CSL is pursuing,
however I don't believe they are planning to deliver end-to-end
functionality in the near term - although it is hard to say since they
haven't been very forthcoming with their plans.

>  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...

I have taken a quick look at groupserver.  It would be very helpful if
someone itemized all the features so we had a good model to look at. 
I've been working from from the Yahoo Grouips functionality.

>  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...

isn't phplist entirely there?

>  moodle has it by default ???? is that true?(hard to read their site)

not familiar.

>  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!

yes - like I agree - however imho it isn't going to get done this way
anytime soon.

> 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
>>
>>
>>
>>  
>>
>
>