entity structure for stored messages
i was wondering if we may benefit from some entity sub-structure to stored messages. let me explain:
right now, org.jboss.mail.mailbox.entity.message.LocalMessage is the only entity bean interface we have, and there are basically two methods that allow access to the data of any given message: getBody() and getHeaders(), both of which return strings that need to be parsed. headers are ultimately parsed into their respective lines and bodies are parsed into their respective BodyParts, when appropriate. drilling down into the headers part, there are many standard headers that are repeated in every email, like date, subject, etc etc, and further, some headers contain references to other entities we will eventually want to persist in the database, like email addresses on 'from' or 'to' header lines.
if we have some entity structure to reflect the actual regular structure in email messges themselves, we'll be able to do things like search for all email messages from a particular email address, without having to load in all the bodies and headers from all the stored emails in the database; we'd rather just execute an ejb-finder method. there are lots of other examples of neat things that can be done easily and efficiently, too, if we create some structure in the Entity layer.
so, for instance, rather than have LocalMessage have a CMP field 'headers', it may be useful to have a CMR field 'headers', in a many-to-many relationship with a 'header' entity bean.
the 'header' entity bean would then have a CMR field in a many-to-one relationship with a 'header-type' bean. the 'header' entity bean would also have a CMP field for the string value of the header, such as the actual subject of a message.
the 'header-type' bean would have a CMP field with the name of the header-type, such as 'Subject' etc.
the LocalMessage object would also have a CMR field called 'from' in a one-to-many relationship with an 'email-address' bean, and another CMR field called 'to' which would be in a many-to-many relationship with the 'email-address' bean, etc.
basically what i'm proposing is something as close as possible to 'third normal database form' for our entities, given that they're ultimately stored in a relational database. if the persistent store is in third normal form, whether in the database layer or entity layer, its very easy to query and manipulate since all the dependencies are tightly controlled and redundancies essentially eliminated.
if we want to eventually support things like contact lists, calendaring, etc, this kind of structure may become especially useful. in that case, we may even want to deepen the structure and add beans like 'person' that represent a person, with a CMR field in a one-to-many relationship with the 'email-address' bean, for instance.
this short note just scratches the surface of this topic, but i wanted to get some early feedback on it.
mike
