On Mon, 2003-10-27 at 15:06, Kevin McCann wrote:Undecided, I am only just starting the development stage now (overlapping with the end of my requirements). This is a decision I will have to make over the next two weeks and as I am relatively inexperienced I shall be asking a lot of questions and doing lots of research. I included it as a requirement, even though it is an obvious one, so I can relate my design directly back to each requirement.
To me, this is the single most important part. How do you intend to
store the messages?
I have to explore as many of the options as time permits for my report. Although I like the idea of being able to do an SQL style query based on header information which would be stored as seperate fields.Maybe others don't give a fig but I think that if archived messages were
to be stored in an easy-to-access database then life would be good.
I agree, although I don't know if I'd store everything in MySQL.
There are a couple of ways I could see slicing things. You could storeTwisted eh? I will have to look into that.
one message per file a la MH, with some elaboration to avoid inode
exhaustion. Or you could store everything in an mbox file with a file
offset index. Or perhaps store everything to an nntp server (Twisted
would make a nice platform for this <wink>).
This is where my ignorance shines, could you elaborate a bit on this part please? By this, do you mean you want all queries to be setup and executed by a user through the web interface? Why can't messages be massaged from the file system?Also, I really want the next generation archiver to do everything through cgi (or equivalent programmatic interface). The ability to massage the messages on the way out to me outweighs the benefits of vending messages directly from the file system.
Thanks
Iain
_______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
