See also: IRC log
<trackbot> Date: 18 March 2010
<marengo> ScribeNick: marengo
<dom> Messaging API Editors draft
<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
<fjh> why not say, that the message has been sent
<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]
-> 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].
<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
<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