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

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.

>> 2. We currently model a message as a (text) "body" and an array of blobs that we call "attachments."
>> Please use the terminology from RFC 2045 section 2 in order to model MIME.  Also note that the model we use might very well be sane for composing e-mails (we have a choice about the complexity of the messages that we permit to be constructed through this API), but that it won't work on the receiving end. A message can have a multipart as its body, any of whose parts can be a multipart or a message by itself. That's not properly modeled in the current API.
> 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?

>> Several of the observations here beg a more general question:  To what extent do we expect this API to be ever taken up outside of widget environments?
> That's a very good question — ideally I'd like to see some simple use cases here for the Web side.

Received on Tuesday, 10 August 2010 17:05:30 UTC