|
From: Jeff S. <jsq...@os...> - 2003-05-22 16:00:05
|
On Thu, 22 May 2003 li...@av... wrote:
> Ok, I agree as well about the messages being in the database in their
> entirety, and that the ma_in_fs field can go away. Jeff, I also dimly
> remember that we decided to treat all message bodies as attachments.
> To indicate that a given message is not a standalone, yes, how about we
> add a "m_parent" field to msg_ids that would contain the m_id of the
> parent message, or would be -1 if the message is a standalone.
Excellent. :-)
> I waffled a lot on this and went the more generic route. Also I
> originally assumed that with a line in msg_headers per header, there
> would be a separate entry (row) for each recipient on the to, cc, bcc
> lines. I have no problem putting the "required" headers into msg_ids --
> [snipped]
I agree here that for ease of searching, we probably want to put "well
known" header lines in specific fields.
> but I believe then we would be simply putting the entire comma-separated
> list as the value of m_to, m_cc, etc. Is this ok with everyone?
I think that's ok. Otherwise we'd have to make yet another table indexed
by message ID, right?
Let's try this approach and see how it works (i.e., that the field
contains the value of the "To:" line, etc.).
For safety's sake (and probably only while we're developing/debugging),
should we stash the entire (unmodified text) header in a table somewhere?
i.e., in case we decide to re-do the schema, we have all the original
header that we can re-build all the tables from? I don't know if this is
a huge deal, and/or if it's helpful, but it might not be a bad idea --
could help with debugging (e.g., compare what ended up in the tables to
what the unmodified header is). Just an idea. :-)
> So...assuming I modify msg_ids ... what will we consider the required
> headers? to, cc, subject, date, ... ?
Heck, let's err on the side of lots of options. The idea here is that we
can search and sort in a million different ways:
- To
- CC
- BCC (for outgoing messages)
- Subject
- Date
- In-Reply-To
- Precedence
- Reply-To
- Sender
- Message-ID (I think we have that already, right? Just mention it to be
complete...)
- Return-Path
- List-Id
- X-Sender
- X-Mailer
- User-agent
- Thread-topic
- Thread-index
- References
- ...?
(I know the X-* ones are not standard, but enough mailers use the ones
that I mentioned that it could be worthwhile -- didn't you always want to
be able to filter by who sends using Outlook Express? ;-)
Here's an issue, though: what happens if the value of any of these header
lines is longer than the length of the "text" field?
--
{+} Jeff Squyres
{+} jsq...@os...
{+} Research Associate, Open Systems Lab, Indiana University
{+} http://www.osl.iu.edu/
|