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

Robin, all,

I would be generally cautious with this approach with different flavors of email implementations. Here are a couple of (broad) initial concerns:

- Binding the API to a specific RFC will cause implementations to translate the headers to their own implementation
- Will require developers to do all the formatting to the according to the RFC (besides typed approach is preferred in a API over a typed approach)

Regards,
Suresh


 


-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Robin Berjon
Sent: Wednesday, August 18, 2010 7:15 AM
To: Thomas Roessler
Cc: María Ángeles Oteo; Frederick.Hirsch@nokia.com; public-device-apis@w3.org
Subject: 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/






---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Wednesday, 18 August 2010 14:09:53 UTC