Re: Review: browser use case; e-mail compatibility? (Re: Message API Status)

On Aug 10, 2010, at 19:05 , Thomas Roessler wrote:
> On 10 Aug 2010, at 15:30, Robin Berjon wrote:
>> On Aug 5, 2010, at 11:06 , Thomas Roessler wrote:
>>> 1. EMail address syntax is a fairly complex beast.  Please refer to specific productions from RFC 5822 when talking about things like e-mail addresses.  (You could either mean an address, a mailbox, or an addr-spec. Note that an address may include a list of mailboxes.) 
>> 
>> In terms of the complexity of what we might need to expose, isn't there a point at which we can cop out and just give a DOMString, leaving it up to a library to expose the vicious intricacies of email syntax (and letting the vast majority of people not care about what is essentially a steaming pile of corner cases)?
> 
> You could model the entire address headers (to, cc, bcc, from) as a DOMString each and not care about the structure at all.

Right. I would tend to think that, while something of a punt, it would be the right thing to do for a v1. Doing this right is pretty damn hard, and the resulting API would expose developers to a lot of complexity that corresponds to things that rarely ever happen. If this interface picks up and it turns out that everyone is rolling out problematic recipient parsing libraries, we can consider an API for it.

>> Any chance that we could "simply" use File API: Directories and Systems to model MIME messages? I guess that a multipart email message could be seen as a VFS (if we had to).
> 
> Interesting idea. Want to try specing it out?

I'm not at all a specialist in MIME, but I wonder if something like the following could work.

interface EmailMessage {
    readonly attribute DOMString textContent;
    readonly attribute Blob[] attachments;
    readonly attribute EntrySync body;
};

The textContent attribute uses some form of simple heuristic to address the cases where one does not want to handle the full power of MIME. It could return the text alternative, or the first text part, or some form of concatenation. Of course if it's a plain and simple email message this is all you get.

The attachments attribute is the same sort of simplified access for the rest. It returns all that textContent doesn't as a flat list of blobs.

The body attribute is from http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#idl-def-EntrySync. It essentially exposes the email message as a file system, in which any multipart part is a directory (recursively) and the rest are files. Some parts may have to be neutered (e.g. to make it read only, unless we want people to manipulate complex MIME) and I have no clue what toURI() might reply (perhaps something with mid: or perhaps something based on localmessage: if anyone can ever explain to me what that is). An alternative would be to make the body be a FileSystemSync rather than an EntrySync; it might be more coherent (it gives us a logical filesystem to reference) but it introduces an extra level of indirection. Finally, depending on message size and device power going for the *Sync option might be optimistic and it may be better to stick to the async variant (or offer .body and .bodySync).

In other words it requires some specifying but I think it's workable. That being said I don't know that we want to do the work before we have a clearer view of where we're going.

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Wednesday, 18 August 2010 12:15:59 UTC