Roy Lambert wrote: >> Did you try to open this mail by MIME >> synapse demo? > > I did, but now I've done it again and figured out a bit more about > multi-part mime emails (I hope) > > It would still be interesting to see an example of best practice on > extracting the data for display.
Ok... first of all, a bit of warning to all who are reading this; I've just gotten out of pub, and am pretty filled up with alcohol content, so there might be some points that need a lot of clarifying... however, this post might be something that opens the minds for other people, so I'm giving it a shot non the less... MIME-encoded message is simply a "one-way tree structure"; this means that not a single "lower level" node will have anything to do with nodes on the "upper level". Nodes that are on the "same level", should normally be considered equal; they are normally just different representations of the same data (a message part whose content-type is text/plain might have a sibling part that is of content-type text/html for example, also - there might be same sorts of parts in different languages (this is very unlikely, though it is one of the examples given by the RFC)). Normally, the messages are decoded into multiple parts using a recursive function - all this does is make certain that all parts are handled; it is the client software's duty to decide which are the parts that should be "displayed". Doing recursion has basically two possibilities; doing "children first" or "siblings first". Whichever way is chosen, depends on the developers, and should not hinder the outcome in any way. However, on my personal experience, I thing that for humans, it's easier to understand the "children first" approach. When doing the decoding on the basis of "children first", we enter each MIME-part, after which we descend to the first child-part of the given part. When there are no more children, we proceed to the next sibling of the part. When there are no more parts to decode, we go "up one level" - back to the parent, and continue (if it has more child parts, we go through them, if not, we go through it's siblings. If it hasn't got any more children or siblings to go through, we go back one level - unless we're on the top level, where there is nowhere to go, which means we're done). Of course - this way we've only managed to go through all the parts of the message. What our software should show for the user, is still undetermined... and that is what distinguishes different client softwares. What is shown is not always "all of the message"; the "message" might have many redundant parts. However, if we don't have all of them, it is impossible to even attempt to make a fair choice... we must have all the parts at our disposal before we can determine if it (a single MIME-part of a message) should be shown to the end user or not. I think ... this message needs someone who is a bit more sober than myself to make it any better "guideline". I tried making sense to a rather simple programmatical problem, but I may have caused even more confusion than what I began with. Hopefully this helps someone :) -- Markku Uttula ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
