W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

RE: CfC: Messaging FPWD

From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Fri, 12 Mar 2010 15:00:13 +0100
To: "SULLIVAN, BRYAN L (ATTCINW)" <BS3131@att.com>, "marco.marengo@telecomitalia.it" <marco.marengo@telecomitalia.it>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C2897523E95@OBEEX01.obe.access-company.com>
Hi,

I agree as well.
The unnecessary burden should be cut as low as possible, it should not come to JS level if not necessary.
BONDI messaging app tells the platform what it wants, instead of searching for it in the whole stream of potential events.

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of SULLIVAN, BRYAN L (ATTCINW)
Sent: Friday, March 12, 2010 2:35 PM
To: marco.marengo@telecomitalia.it; public-device-apis@w3.org
Subject: Re: CfC: Messaging FPWD

I agree with Marco. This will otherwise become a burden for developers of webapps, device resources, and a risk factor for reliability (imagine all the bizarre content you would need to be ready to ignore, which depends upon being able to distinguish it from what you want/expect). The filters are in Bondi for a good reason, and they should be here too.

Bryan Sullivan | AT&T

----- Original Message -----
From: public-device-apis-request@w3.org <public-device-apis-request@w3.org>
To: DAP W3C <public-device-apis@w3.org>
Sent: Fri Mar 12 03:21:38 2010
Subject: Re: CfC: Messaging FPWD

Hi,
before moving to FPWD I'd suggest to extend the subscription method with some basic filters. The rationale is that a generic subscription (e.g. on MessagingManager.EMAIL_TYPE) may generate a big number of callback invocations, forcing each application to implement its own filters.

My proposal for extending the subscribe method is:

int subscribe (in MessagingFilter filter, in OnIncomingMessage messageEventCB, in optional ErrorCallback errorCB);

interface MessagingFilter {
    attribute unsigned short messagingType;
    attribute DOMString from;
    attribute DOMString to;
    attribute DOMString body;
};

As you can see the basic use case (filtering on message type) is still supported, but it is now possible to receive callbacks only when a particular condition on sender and/or receiver and/or body is verified (eg. an email sent by "public-device-apis@w3.org").


Marco Marengo



Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.



________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Kiyoyasu Oishi, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Received on Friday, 12 March 2010 14:00:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:06 GMT