[prev] [thread] [next] [lurker] [Date index for 2003/03/14]
Update of /cvsroot/siesta/siesta In directory sc8-pr-cvs1:/tmp/cvs-serv29387 Modified Files: TODO Log Message: Added some items and thoughts Index: TODO =================================================================== RCS file: /cvsroot/siesta/siesta/TODO,v retrieving revision 1.6 retrieving revision 1.7 diff -u -d -r1.6 -r1.7 --- TODO 11 Mar 2003 14:31:05 -0000 1.6 +++ TODO 14 Mar 2003 14:38:42 -0000 1.7 @@ -1,7 +1,4 @@ -* Could someone update this file who has their finger on the pulse - of the project. - * Web based administration * Improve installation guide/routines @@ -29,3 +26,112 @@ * Simple dump/load commands (for upgrades and backups) * Seperate automatic messages sent out into separate templates. + +And a longer mail which I (simon) sent to Andy Wardley + +On Mon, Mar 10, 2003 at 07:06:07PM +0000, Andy Wardley said: +> I haven't heard of Siesta, but reading between the lines, I'm guessing +> it's a Mailman replacement. Yay! + +Yes. It was ahcked up last Autumn by Richardc, Gregt and I. It's +currently stagnating and occasionally getting worked on by me cos the +other two are bored of it by now. + +> Have you got any code I can look at and/or hack on? Web interfaces +> are my speciality :-) + + http://www.sf.net/projects/siesta/ + +A prototype web interface is here + + http://thegestalt.org/simon/siesta-php/ + +in's currently waiting to be ported to TT (PHP was the only thing I had +available over new year when I hacked this up on a laptop whilst lazing +in beach house in Eastern Australia. THe blue looked, well, less blue +on the Laptop screen as well) + + +Basically my todo list is ... + +** Make the web interface + +And refactor the Siesta code to follow the needs of the web interface +(the module interface was done pretty much blind). + +** Add Per-User plugins. + +Sender plugins are just that, ways of sending mail. So you could have +different plugins for mailing list exploders and normal lists etc etc. +We call this the MBM factor because he wanted a better system for +sending out Popbitch ever week :) Sender plugins are free to ignore +Per-User plugins if they want but in general the plugin sequence looks +like this. + +Mail -> Validate --> Process ---> Send --> Process (for each user) + (Members Only) (Sig Stripping) (Reply to munging) + (Reply-To Munging) (HTML mail) + (Translation?) + + + +THe cool thing about this si that it would be extreemly easy to have a +situation where - mail comes in. Siesta checks to see that it's a) +signed by a known memeber of the list and b) encrypted with the lists's +public key. THen it does the rest of its magic and then, for each user, +signs the mail with its public key and then encrypts with the user's +public key. + +** Administrative tasks + +After trying to find a way to make this a plugin only thing I decided to +make this a List method. + +$list->get_admintasks(); + +* Archive messages + +Ditto. + +$list->get_archivedmessages( 'some data and time span params' ); + + +** Message templates. + +Since we're going to use TT for the Web based interface we thought it +would be nice to have message templates (like 'reply to this message to +subscribe') to be TT templates aswell. In the future this should allow +easy i8ln as well. + + +** Better install + +Maybe. This might just mean providing .debs/.rpms/ports etc etc + + +** Plugin var storgae + +At the moment there's a mildly complicated preference mechanism for +plugins. + +There'sa system wide default, a list wide default, a user wide default +and a per-user per-list option. + +So a system can have Reply-To munging on by default, but turn it off for +the "Reply To munging haters" list. A user can have it off by default +which will override the system and list defaults but he can turn it on +for a specific list instead. + +I'm thinking of maybe dropping this althouygh I quite like it. THe thing +is plugins need some way of storing richer data than key value pairs. SO +I'm thinking of also letting them have an arbitary, persistent data +structure (provided by Pixie) as well. At the moemnt the subscribe +plugin uses user preferences to key track of the md5 hashes it's sent +out but they'd probably better off in a Pixie DB. + + +Like I said before, there's really no more than a week's work in there +... it's just getting a week to do it that's the problem. + +Simon +
Generated at 13:57 on 01 Jul 2004 by mariachi 0.52