Oct 3, 2005, 3:22 AM
Post #3 of 3
Re: [benn600] Surface level...what if and how difficult
[In reply to]
How difficult would it be to write a simple email retrieval program? I have my own email server which has an http email client but it is only a demo and it will probably expire after a short while. Therefore, I'd like to see if I could make my own client. Can someone summarize how difficult this would be in general terms? I am learning mysql now and am starting to get above-beginner with it, so this would make the site a little easier.
Writing an email application is harder than you might think. Which is why most webmail programs are so bad.
Oh, it's simple enough to download messages using Net::POP3 or Net::IMAP but the problem comes when you get MIME-encoded attachments.
There are also a whole load of new problems when it comes to composing new mail. Do you understand all the mail headers that you should create? For example, can you explain the difference between the 'References' and 'In-Reply-To' headers.
If you're serious about this then take a look at the Perl Email Project. They are building a simple and consistant set of modules for handling email messages.
This question can be asked more easily by applying the concept to a message board/forum. When messages are stored, are they ALL stored in one single table/entity? And then each instance/entry will just have a foreign key specifying which thread it is in? The thread names would be listed in another entity. Is this the general form? I used to use .txt files and I even made a somewhat useful forum of my own but I use a method that most forums probably don't use. Each time a new thread is created, a new .txt file is created. Then, when the admin deletes a thread, that file is deleted and the thread name is deleted from the thread list. I don't think this is a common way to store data in a mysql database, though, because you would have a table for every thread--making SHOW DATABASES; absolutely huge over time. Does having one table end up slowing the database down because each thread opened has to scan the entire table for messages with thread id of 53?
You would have one table that contains all of your messages. Each message would have (amongst other things) a unique id and a column containing the id of its parent message. Top level messages would have an id of 0. It's therefore simple to create a query that brings back a) all top level queries (i.e. all conversations on the messageboard) and b) all children of a given query.
Having indexes on both of these tables would help to make these queries as fast as possible.
Once again I should point out that discussion of database modelling and query optimaisation isn't really what this board is for so you might well be better off finding a board that specialises in these topics.
Dave Cross, Perl Hacker, Trainer and Writer
Get more help at Perl Monks