Device APIs and Policy Working Group F2F Meeting Day 3 -- 18 Mar 2010

<trackbot> Date: 18 March 2010

<marengo> ScribeNick: marengo

Messaging API

<darobin> RuthVazquez, should be good now

<RuthVazquez> yes it is! thank you

maxf: we'll have a walthrough of the document
... we're supporting sms, mms, email
... with basic functionalities: create, send, subscribe
... first sections are boiler-plate

<dom> [the messaging API relies on supportsType(), while the more JS-typical way of doing this is to rely on the existence of an interface]

maxf: MessagingManager: create, supports, subscribe, unsubscribe methods

darobin: what about putting messagingType in MessageProperties?

dom: typical usage is something like messaging.email.create()

darobin: or something like createEmail(), createSMS(), ...

maxf: it's probably less scalable

AnssiK: it's similar to the Capture API, we have 3 separate methods

maxf: so it's message.mms.create(..) VS message.createMMS(..)

<scribe> ACTION: maxf to make subscribe() method use events [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action01]

<trackbot> Created ACTION-132 - Make subscribe() method use events [on Max Froumentin - due 2010-03-25].

bryan: what about filtering?

<marengo_scribe> -> a suggestion for extending messaging filtering: http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0131.html

bryan: i'd like to subscribe to binary messages
... there's a reason for apps: they're efficient, compressed
... and delivered to a port

dom: it's also a matter of minimization

drogersuk: suggest to have a look at BONDI 1.1 Messaging API

<marengo_scribe> BONDI 1.1 Messaging API

bryan: we need a simple set of filters for typical use cases

maxf: difficult to define powerful filters, it's an application problem

darobin: can we reuse event targets
... and subclass the EventListener class

<dom> ACTION-132?

<trackbot> ACTION-132 -- Max Froumentin to look at messaging subscribe with filtering and events -- due 2010-03-25 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/132

<dom> [message.create() should really be renamed message.send()]

maxf: back to messaging.mms.create(...) vs messaging.createMMS(...)

dom: the 2nd would be more consistent with other apis

<dom> dom: (unless we need additional specialized methods per messages types)

ilkka: it's different from the capture API, what if someone wants to create a twitter msg?

<dom> s/illka/ingmar/

maxf: we'll use messaging.createMMS(...)

<dom> ACTION: Maxf to change message.create(TYPE) to message.createTYPE() [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action02]

<trackbot> Created ACTION-133 - Change message.create(TYPE) to message.createTYPE() [on Max Froumentin - due 2010-03-25].

maxf: supports() becomes unnecessary

<dom> AnssiK: message.send() doesn't need to have itself as a parameter

<fjh> Chair: Frederick_Hirsch, Robin_Berjon

richt: Message should inherit from MessageProperties

bryan: is the ID assigned when the message is created?

maxf: when you create() the message, the object has its ID

darobin: messagingType -> type

<dom> maxf: errorCallback in send should be optional

darobin: we keep timestamp as it is, it doesn't keep timezone information

<dom> robin: probably less of a problem that Message.timestamp loses timezone info; we can move to TimezonedDate() if we get define that

dom: is timestamp referred to creation or send/receive time?

bryan: could it be updated to the last event of the lifecycle?

dom: normally if you receive an email you only can see when it was sent, not when you received it

<dom> ACTION: maxf to replace Message.timestamp with Message.sent and Message.received [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action03]

<trackbot> Created ACTION-134 - Replace Message.timestamp with Message.sent and Message.received [on Max Froumentin - due 2010-03-25].

richt: SuccessCallback isn't defined

maxf: what do we need for successCB?

darobin: it could be just a function() object [see File API]

richt: in other APIs we return the updated (server-verified) object

maxf: this is a design pattern, it should be applied to other apis as well

dom: let's keep it simple for v1

<dom> ACTION-113: also check that "empty" callbacks should be described as Function

<trackbot> ACTION-113 Propose a checklist of points to verify before LC for APIs, including REST-ful, minimization, policy-binding notes added

maxf: in this case we don't need to receive a Message object back
... there are no use cases for it

<richt> ACTION: Summarize the SuccessCallback patterns and use cases for each method (i.e. use Function or SuccessCallback(Message message)) [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action04]

<trackbot> Sorry, couldn't find user - Summarize

<richt> ACTION: richt to summarize the SuccessCallback patterns and use cases for each method (i.e. use Function or SuccessCallback(Message message)) [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action05]

<trackbot> Created ACTION-135 - Summarize the SuccessCallback patterns and use cases for each method (i.e. use Function or SuccessCallback(Message message)) [on Richard Tibbett - due 2010-03-25].

<dom> ACTION: maxf to change message callbacks to be of type Function [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action06]

<trackbot> Created ACTION-136 - Change message callbacks to be of type Function [on Max Froumentin - due 2010-03-25].

maxf: MessageProperties interface has the usual fields that are found in the 3 types we considered
... do we have sequences or arrays?

<dom> ACTION-113: also check usage of Array vs sequences

<trackbot> ACTION-113 Propose a checklist of points to verify before LC for APIs, including REST-ful, minimization, policy-binding notes added

<dom> WebIDL Sequences

<dom> WebIDL Arrays

bryan: so there's multiple distinct "to:" addresses

<scribe> ACTION: maxf to change sequences into arrays [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action07]

<trackbot> Created ACTION-137 - Change sequences into arrays [on Max Froumentin - due 2010-03-25].

darobin: attachment should be a list of blobs

<darobin> ACTION: Max to change array of DOMString attachments to array of Blobs [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action08]

<trackbot> Created ACTION-138 - Change array of DOMString attachments to array of Blobs [on Max Froumentin - due 2010-03-25].

maxf: section 7: can it be removed?
... section 8: it shouldn't say we support multiple accounts at the API level

richt: should we support a subscribe() targeted to just one account?

darobin: then there's a need to be able to enumerate accounts, it gets complicated
... what happens when you set an attribute which is not supported by the type? (Eg. attachment for SMS)
... we should re-write that normative statement (section 5 - supported messaging types)

<scribe> ACTION: maxf to fix section 5 "supported messaging types" [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action09]

<trackbot> Created ACTION-139 - Fix section 5 "supported messaging types" [on Max Froumentin - due 2010-03-25].

ilkka: attachments - how do you know the mimetype if it's a blob?

darobin: we should use a File array

RESOLUTION: multiple account management is left to the UI

<dom> ACTION: Maxf to turn array of paths into array of files for attachments in Messaging API [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action10]

<trackbot> Created ACTION-140 - Turn array of paths into array of files for attachments in Messaging API [on Max Froumentin - due 2010-03-25].

bryan: "from" field should not be settable

<dom> close ACTION-138

<trackbot> ACTION-138 Change array of DOMString attachments to array of Blobs closed

<scribe> ACTION: maxf to update the spec to make "from" field not writable [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action11]

<trackbot> Created ACTION-141 - Update the spec to make "from" field not writable [on Max Froumentin - due 2010-03-25].

<dom> ACTION-138: overtaken by ACTION-140

<trackbot> ACTION-138 Change array of DOMString attachments to array of Blobs notes added

richt: when is "from:" set? at creation time?

dom: at send() time

<dom> dom: leaking the From is probably not a good idea

<dom> ... might not want to share my phone number or email with the app/site

bryan: does send() popup an UI which allows the user to review the message?
... and does the UI allow to select a default account for such operation?

<dom> richt: should we have two separate interfaces for Incoming and Outgoing messages?

<dom> dom: with different readonly properties too

<dom> richt: would distinguish From in Incoming and Outgoing

<dom> dom: and bcc would also be different

<dom> maxf: I'll define two types and see what it looks like

<richt> From would be available in incoming (read-only) but not settable or readable in outgoing

<dom> ACTION: maxf to propose two interfaces Outgoing and Incoming messages for messaging API [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action12]

<trackbot> Created ACTION-142 - Propose two interfaces Outgoing and Incoming messages for messaging API [on Max Froumentin - due 2010-03-25].

<dom> PROPOSED RESOLUTION: Publish messaging API as FPWD once actions items are implemented

no objections

RESOLUTION: Publish messaging API as FPWD once actions items are implemented

bryan: what's the resolution about filters

maxf: we'll look at the BONDI proposal

AnssiK: section 6.3.2 mentions Outgoing messaging folder. it should be rephrased to state that a UI will allow to choose the account

Policy/Privacy/Security

<fjh> why not say, that the message has been sent

Gallery

<marengo_scribe> the Gallery API

<fjh> s/<marengo> Topic: Policy\/Privacy\/Security//

wonsuk: the spec is inspired by the BONDI spec
... section 2.1 more examples are needed
... [describes the 2.1 usage example]

<dom> Request for review of MAWG "API for Media Resource"

wonsuk: section 3 is about security & privacy

darobin: there will be an external document, it will be referred here
... moves to section 4

<richt> Gallery API - get(..) vs find(..) ??

darobin: galleries interface. getGalleries() offers access to the Media Galleries
... [describes gallery interface]
... GalleryProperties contains details about a specific Gallery

richt: GallerySuccessCB can be a function object

AnssiK: it might be beneficial to pass the object we're working on to the callback

aguillou: can you add/remove objects from a gallery?

wonsuk: yes, such methods will be added

richt: what's open() actually doing

wonsuk: it could trigger some memory managerment options for allocating resources

AnssiK: open() should be in its own interface, and be called synchronously

dom: do we want an open() or a find()?
... a find() with parameters for limiting the number of items

AnssiK: can we reuse something from MAWG?

wonsuk: it support 20+ media types

AnssiK: can we also layer something on the File API

bryan: the delta is the access to meta-data

AnssiK: what has been the implementation experience in bondi?
... any feedback?
... I'll send my comments on the list, and would appreciate some feedback from BONDI

<richt> latest BONDI gallery spec: http://bondi01.obe.access-company.com/1_1_5179_145/gallery.html

<scribe> ACTION: AnssiK to provide feedback on the list [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action13]

<trackbot> Sorry, couldn't find user - AnssiK

<dom> ACTION: Anssi to provide feedback on the list on Gallery API [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action14]

<trackbot> Created ACTION-143 - Provide feedback on the list on Gallery API [on Anssi Kostiainen - due 2010-03-25].

<richt> BONDI Gallery demo: http://bondi01.obe.access-company.com/1_1_5179_145/gallery.html#ifGallery

wonsuk: goes back to Gallery interface (changeView method)
... there is a getMediaObject for retrieving a media object by id
... GalleryProperties interface contains metadata about the gallery
... MediaObject IF is missing some functions (add, update, find, delete) which will be defined soon
... MediaObjectProperties IF should inherit something from MAWG

<dom> API for Media Resource 1.0

bryan: [API for Media Resource] spec is intended to define a common set of attributes which are common to all formats
... we should try to use a consistent set or properties

<dom> Mapping tables of Ontology for Media Resource

<dom> Mapping to iTunes format

wonsuk: ViewType IF describes how a gallery is displayed

<dom> [ViewType really is a filter/sorter interface; it needs to be renamed in something easier to relate to]

wonsuk: ordering criteria, date filters

AnssiK: there could be a sort() method in Gallery

bryan: what about random filtering (e.g. shuffle)

AnssiK: it could be done by the app, if there's easy access to metadata

darobin: we're running out of time

bryan: let's align this with other filters in DAP APIs (eg. media item file size)

drogersuk: there's some basic filter in ViewType

darobin: yes, it should be consistent through all the apis

wonsuk: there are no use cases in the spec, yet
... that's all for gallery

[5 minutes break]

Policy/Privacy/Security

-> http://dev.w3.org/2009/dap/privacy-reqs/ Privacy Reqs draft

fjh: goes through the updated version
... section 6: privacy requirements
... mentions minimization
... replicates the table we designed
... this could go FPWD

<dom> ACTION: Dom to take an editorial pass at privacy-reqs [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action15]

<trackbot> Created ACTION-144 - Take an editorial pass at privacy-reqs [on Dominique Hazaël-Massieux - due 2010-03-25].

-> http://dev.w3.org/2009/dap/policy-reqs/ Policy Reqs draft

fjh: scrolls the doc
... section 8 use cases
... section 9: requirements
... concerned about the next steps (section 9.4.1, 9.4.2)

<scribe> ACTION: bryan to provide an architectural flow for Policy Reqs [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action16]

<trackbot> Created ACTION-145 - Provide an architectural flow for Policy Reqs [on Bryan Sullivan - due 2010-03-25].

LauraA: what's the relation with the joining of the BONDI and Nokia proposals (it is ongoing work)

<dom> [I think we would better served with use cases than requirements for policy]

<dom> Dave: the best way is probably to go ahead with the policy proposal

<dom> ... I think we'll find a common ground for the trust domains questions

<dom> Frederick: so I'll remove the privacy stuff out of policy-reqs, and we'll leave policy-reqs on the side until we get a better idea of whether we want to do something with it

<dom> Frederick: the threats considerations should also address the security questions

<dom> ... what about sending a CfC for privacy-reqs as we agreed?

<dom> ACTION: Frederick to send a CfC on privacy-reqs when Dom is done with edits [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action17]

<trackbot> Created ACTION-146 - Send a CfC on privacy-reqs when Dom is done with edits [on Frederick Hirsch - due 2010-03-25].

other APIs

<dom> David: for Commlog, in BONDI, we are moving into a more general telephony API

<darobin> AnssiK: what's the use case for receiving a call programmatically

<darobin> Bryan: customer care widget

<darobin> ... David's point is that the API has changed to only do logs, but the calls are in the messaging API

<darobin> David: it's cleaner

<darobin> ... you might want to consider it, but I realise it's not in the charter

<darobin> Bryan: in principle it's the ability to know abotu call events

<darobin> FJH: does telephony expand the scope and amount of work

<darobin> ... so it's the same functionality in a different place?

<darobin> David: BONDI has a commslog that does logging, then later we'll extend to calls — but that's out of DAP charter

<darobin> David: if you were to drop Commslog we wouldn't be against it, so long as its information goes somewhere

<dom> trackbot, you are wrong

<trackbot> Sorry, dom, I don't understand 'trackbot, you are wrong'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<dom> trackbot, thanks

<trackbot> You are most welcome, dom

Charter

<darobin> FH: it's a tight schedule

<darobin> ... it'll take at least a quarter to exit LC+CR

<darobin> ... that means we have to have things done soon

<darobin> Dom: one of the reason we have the end date is because people are eagerly awaiting the result

<darobin> ... our work is more relevant if it finishes on time

<darobin> FH: we've agreed on where we're going

<darobin> .... things are well on their way

<darobin> ... for 10Q2-Q3 we have to get everything on Rec track

<darobin> ... [explains process really, really fast]

<darobin> ... you don't want to wait until CR before you do some interop testing

<darobin> ... if we could avoid multiple LC it's nice

<darobin> ... after CR, PR

<darobin> ... next year needs to be all about CR

<darobin> .... so we have to finish LCs this year

<darobin> ?

<bsulliva> scribenick: bsulliva

fjh: gives an overview of the status, available on the home page
... tasks API, why are we waiting, is this simple with input contributions

dom: it may be as complicated as calendar

fjh: wait for calendar and layer it on top?
... can we draft the non-recurrent stuff first?

dom: we need at least an editor volunteer to get started

fjh: what happens if we get no volunteers

drogersuk: we can query the BONDI supporters that are DAP members who may be able to provide input

<dom> ACTION: David to look for an editor for the Tasks API [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action18]

<trackbot> Created ACTION-147 - Look for an editor for the Tasks API [on David Rogers - due 2010-03-25].

fjh: if we know early, we will be better able to deal with the options

richt: calendar will help with the issues

fjh: applauncher, we need an editor

wonsuk: volunteers as editor

bsulliva: I can provide input

wonsuk: 4-6 weeks to get a draft started

fjh: appconfig, we dropped this and have nothing more to do
... user interaction, to webapps?

bsulliva: the modify the user interface e.g. menus are not covered by window modes

fjh: do we need to do those at this time?

drogersuk: this should be done in V1

fjh: anssi suggested this was covered by the webapps API's

bsulliva: we need someone to survey webapps to determine the gaps

<dom> Anssi's email on user interaction API requirements

anssi: we have some options in HTML5 spec re menu controls

fjh: is someone familiar with BONDI able to decide if we have filled the gaps already?

bsulliva: I will take this one on

<dom> ACTION: Bryan to compare user interaction input with what already available in HTML5 / WebApps [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action19]

<trackbot> Created ACTION-148 - Compare user interaction input with what already available in HTML5 / WebApps [on Bryan Sullivan - due 2010-03-25].

darobin: will review what Bryan writes

fjh: on commlog, what are the next steps

<fjh> david suggests that part goes into messaging, and commlog might be renamed telephony

drogersuk: we did not make a resolution - we need to make sure what was intended for commlog goes into messaging and the rest into something else
... a suggestion is to pull the messaging parts out and defer the rest to a telephony API for V2

anssi: you can use commlog to find the people you want to interact with

richt: we could take the approach of a generic log

drogersuk: we would be creating new concepts there, not basing that upon established work

dom: commlog is more like accessing your mailbox

fjh: who can help with the commlog draft?

dom: we could add the read/log functions to the messaging API

drogersuk: we have an action to review the messaging input from BONDI for guidance on that
... there are use cases where call log is useful

bsulliva: we could just call what's left as the telephony API

fjh: the proposal is for messaging to have the messaging log functions

drogersuk: we realized in BONDI that the logs should be associated with the feature

<fjh> bsullivan notes messaging is a feature set, message log is a feature

dom: without the policy framework in place, putting those functions into a common module also makes sense (one that is focused on log use, regardless of the type)

richt: are you saying they should be common, as a distinct messaging API with log features makes more sense

drogersuk: with focus on making developers's life easier, we decided to focus on the distinct types of services, e.g. messaging and telephony as distinct things

dom: communication is a common function regardless of the communication type

fjh: we said in the privacy discussion that you need access to the logs

dom: we maybe need an issue to continue this

<dom> ISSUE: should Communication Logs be part of the messaging API or part of a telephony API?

<trackbot> Created ISSUE-82 - Should Communication Logs be part of the messaging API or part of a telephony API? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/82/edit .

<dom> ACTION: David to summarize discussions on BONDI regarding Communication Log/messaging/Telephony API [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action20]

<trackbot> Created ACTION-149 - Summarize discussions on BONDI regarding Communication Log/messaging/Telephony API [on David Rogers - due 2010-03-25].

fjh: re other deliverables, for interoper there is work to make sure things work well, so they are better prepared for the formal call
... not sure the nature of DAP API's fit that model
... the call for implementations at CR can be prefaced with interop testing within the group
... that is easier if you have interop testing in advance
... do we have enough vendors here to do that pre-interop, and who wtites test cases?
... who will run them?

darobin: we will do both

drogersuk: a lot more than two interoperable implementations based upon BONDI will likely implement the DAP API's

anssi: does the approach used in webapps work for us?

fjh: the real question is who?

seungyun: is it possible to base the testing on prototypes of web runtimes?

<fjh> we should confirm informal interop in June

dom: I think we should require at least two browsers and web runtimes

<fjh> dom notes will need two browser implementations plus 2 web runtime

fjh: a virtual interop may make sense

bsulliva: maybe some of the BONDI test framework would be useful to DAP

<dom> ACTION: David to send BONDI experience with testing for device APIs [recorded in http://www.w3.org/2010/03/18-dap-minutes.html#action21]

<trackbot> Created ACTION-150 - Send BONDI experience with testing for device APIs [on David Rogers - due 2010-03-25].

drogersuk: there might be 30 or more implementations to consider in this case
... we would like to follow similar approaches as Marcos did on the widgets P&C

fjh: testable assertions may an issue for policy
... getting started on this by July should give us time
... re liaisons, do we need to worry about accessibility in API's?

darobin: have no concerns that come to mind

bsulliva: requiring user interaction is a concern for usability

fjh: anything else?

<dom> Future Work for DAP

drogersuk: do we have a wish list for V2?

fjh: should provide a heads up if it might inform our current work

darobin: AOB?

<dom> RESOLUTION: Thanks Jirka for hosting us!

<richt> Thanks!

fjh: once, twice, adjourned

- DRAFT -

Device APIs and Policy Working Group F2F Meeting Day 3

18 Mar 2010

Attendees

Contents

Messaging API

Policy/Privacy/Security

Gallery

Policy/Privacy/Security

other APIs

Charter

Summary of Action Items

Scribe.perl diagnostic output