RE: CfC: Messaging FPWD

Hi all, 
While I can add filters as proposed, I'm not quiet sure how useful they
really are to developers. Some considerations:

1) App listening for very specific message content (e.g. A widget that
only pops up all messages sent to "public-device-apis@w3.org"). Just
looking at the list as of this moment, this would not catch all messages
on the list (some have "public-device-apis@w3.org" in "to", some in
"cc"). Then we need to add more specific matching rules which tends to
become ugly pretty quickly (doable, but adds complexity). Actually, more
often I'd probably be more interested in using filters to avoid some
messages (e.g. don't bother me with mailing list events).

2) General messaging app where I want to display new messages according
to some set of rules (e.g. Only messages sent from my list of friends
("from: Abe", "to: Bob", "to: Charlie", "to: myself" ). In this case the
developer will probably be interested in the sum of all filters, not
having three subscribe events (two for "to", and one for "from"). Again,
solvable, but quickly becomes quite complex in the general case. 

3) Finally, in comparison with e.g. Filters for searching contacts or
calendar data, I'd expect to message subscription filters to have a much
longer life time, and probably even stay around next time I use the app.


In the end, yes we can add filters, but to make it really useful we'd
probably need make it complicated enough so that writing a specialized
filter in the app itself is no longer an overwhelming task. 

(But maybe it's not writing the filter that is the problem, but the
arrival of a lot of unwanted subscription events to the app?)

Best regards,
Niklas

> -----Original Message-----
> From: public-device-apis-request@w3.org 
> [mailto:public-device-apis-request@w3.org] On Behalf Of Marcin Hanclik
> Sent: den 12 mars 2010 15:00
> To: SULLIVAN, BRYAN L (ATTCINW); 
> marco.marengo@telecomitalia.it; public-device-apis@w3.org
> Subject: RE: CfC: Messaging FPWD
> 
> 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 Monday, 15 March 2010 09:39:35 UTC