Barry Warsaw wrote:
On Mon, 2003-10-27 at 15:06, Kevin McCann wrote:
To me, this is the single most important part. How do you intend to store the messages?
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.
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.
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.
There are a couple of ways I could see slicing things. You could store 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>).
Twisted eh? I will have to look into that.
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.
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?
Thanks
Iain