08:03:31 <RRSAgent> RRSAgent has joined #dap
08:03:31 <RRSAgent> logging to http://www.w3.org/2010/03/18-dap-irc
08:03:33 <trackbot> RRSAgent, make logs world
08:03:33 <Zakim> Zakim has joined #dap
08:03:35 <trackbot> Zakim, this will be DAP
08:03:35 <Zakim> ok, trackbot; I see UW_DAP(F2F)3:30AM scheduled to start 33 minutes ago
08:03:36 <trackbot> Meeting: Device APIs and Policy Working Group Teleconference
08:03:36 <trackbot> Date: 18 March 2010
08:03:41 <dom> dom has changed the topic to: agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0079.html
08:03:46 <dom> Chair: Robin, Frederick
08:03:59 <dom> s/Teleconference/F2F Meeting Day 3/
08:04:02 <JohnsonW> JohnsonW has joined #dap
08:04:08 <dom> Present+ Dominique_Hazael-Massieux
08:05:15 <LauraA> LauraA has joined #dap
08:06:42 <marengo> Present+ Marco_Marengo
08:08:02 <wonsuk> Present+ Wonsuk_LEE
08:08:13 <Seungyun> Seungyun has joined #dap
08:08:20 <marengo> ScribeNick: marengo 
08:08:22 <JohnsonW> Present+ Johnson_Wang
08:08:25 <LauraA> Present+ LauraA
08:08:45 <Kangchan> Kangchan has joined #dap
08:09:45 <AnssiK> AnssiK has joined #dap
08:10:26 <AnssiK> Present+ Anssi_Kostiainen
08:12:33 <dom> -> http://dev.w3.org/2009/dap/messaging/ Messaging API Editors draft
08:13:02 <marengo> Topic: Messaging API
08:17:24 <Zakim> UW_DAP(F2F)3:30AM has now started
08:17:28 <RuthVazquez> Present+ Ruth_Vazquez
08:17:31 <Zakim> +Ruth_Vazquez
08:18:51 <ilkka> Present+ Ilkka_Oksanen
08:18:56 <darobin> darobin has joined #dap
08:19:30 <bryan> bryan has joined #dap
08:19:46 <bryan> present+ bryan_sullivan
08:19:47 <Zakim> +??P1
08:19:59 <darobin> Zakim, ??P1 is DAP-In-Prague
08:19:59 <Zakim> +DAP-In-Prague; got it
08:20:11 <fjh> fjh has joined #dap
08:20:19 <darobin> RuthVazquez, should be good now
08:20:26 <fjh> zakim, who is here now?
08:20:26 <Zakim> I don't understand your question, fjh.
08:20:30 <RuthVazquez> yes it is! thank you
08:20:33 <fjh> zakim, who is here?
08:20:33 <Zakim> On the phone I see Ruth_Vazquez, DAP-In-Prague
08:20:34 <Zakim> On IRC I see fjh, bryan, darobin, AnssiK, Kangchan, Seungyun, LauraA, JohnsonW, Zakim, RRSAgent, wonsuk, drogersuk, marengo, RuthVazquez, arve, blassey, Marcos, ilkka, trackbot,
08:20:36 <Zakim> ... dom
08:21:33 <marengo> maxf: we'll have a walthrough of the document
08:21:47 <marengo> .. we're supporting sms, mms, email
08:21:59 <marengo> .. with basic functionalities: create, send, subscribe
08:22:31 <marengo> .. first sections are boiler-plate
08:23:16 <richt> richt has joined #dap
08:23:17 <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]
08:23:18 <marengo> .. MessagingManager: create, supports, subscribe, unsubscribe methods
08:23:26 <richt> Present+ Richard_Tibbett
08:23:59 <marengo> darobin: what about putting messagingType in MessageProperties?
08:24:39 <marengo> dom: typical usage is something like messaging.email.create()
08:24:50 <arve> arve has left #dap
08:24:59 <marengo> darobin: or something like createEmail(), createSMS(), ...
08:25:16 <marengo> maxf: it's probably less scalable
08:25:43 <marengo> AnssiK: it's similar to the Capture API, we have 3 separate methods
08:25:58 <aguillou> aguillou has joined #dap
08:26:22 <marengo> maxf: so it's message.mms.create(..) VS message.createMMS(..)
08:26:35 <aguillou> Present+Aurelien_Guillou
08:27:50 <marengo> ACTION: maxf to make subscribe() method use events
08:27:50 <trackbot> Created ACTION-132 - Make subscribe() method use events [on Max Froumentin - due 2010-03-25].
08:28:10 <marengo> bryan: what about filtering? 
08:28:46 <marengo> -> a suggestion for extending messaging filtering: http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0131.html
08:29:18 <marengo> bryan: i'd like to subscribe to binary messages
08:29:48 <marengo> .. there's a reason for apps: they're efficient, compressed
08:29:58 <marengo> .. and delivered to a port
08:30:29 <marengo> dom: it's also a matter of minimization
08:31:43 <marengo> drogersuk: suggest to have a look at BONDI 1.1 Messaging API
08:31:58 <marengo> -> http://bondi.omtp.org/1.1/apis/messaging.html BONDI 1.1 Messaging API
08:32:06 <ingmar> ingmar has joined #dap
08:32:23 <marengo> bryan: we need a simple set of filters for typical use cases
08:32:29 <ingmar> present+ Ingmar_Kliche
08:33:14 <marengo> maxf: difficult to define powerful filters, it's an application problem
08:33:27 <marengo> darobin: can we reuse event targets
08:33:50 <marengo> .. and subclass the EventListener class
08:34:23 <fjh> Regrets: Thomas_Roessler, Google members
08:34:30 <dom> ACTION-132?
08:34:30 <trackbot> ACTION-132 -- Max Froumentin to look at messaging subscribe with filtering and events -- due 2010-03-25 -- OPEN
08:34:30 <trackbot> http://www.w3.org/2009/dap/track/actions/132
08:35:44 <dom> [message.create() should really be renamed message.send()]
08:36:14 <marengo> maxf: back to messaging.mms.create(...) vs messaging.createMMS(...)
08:36:28 <marengo> dom: the 2nd would be more consistent with other apis
08:37:39 <dom> dom: (unless we need additional specialized methods per messages types)
08:37:52 <marengo> ilkka: it's different from the capture API, what if someone wants to create a twitter msg?
08:38:09 <dom> s/illka/ingmar/
08:40:00 <marengo> maxf: we'll use messaging.createMMS(...) 
08:40:35 <dom> ACTION: Maxf to change message.create(TYPE) to message.createTYPE()
08:40:35 <trackbot> Created ACTION-133 - Change message.create(TYPE) to message.createTYPE() [on Max Froumentin - due 2010-03-25].
08:40:46 <danielcoloma> danielcoloma has joined #dap
08:40:50 <jmarting> jmarting has joined #dap
08:41:11 <jmarting> Present+ Jesus_Martin
08:41:13 <marengo> maxf: supports() becomes unnecessary
08:42:14 <fjh> Present+ Frederick_Hirsch, Robin_Berjon
08:42:17 <dom> AnssiK: message.send() doesn't need to have itself as a parameter
08:42:28 <fjh> Chair:  Frederick_Hirsch, Robin_Berjon
08:42:49 <marengo> richt: Message should inherit from MessageProperties
08:43:35 <marengo> bryan: is the ID assigned when the message is created?
08:44:05 <marengo> maxf: when you create() the message, the object has its ID
08:45:23 <fjh> fjh has joined #dap
08:45:35 <marengo> darobin: messagingType -> type
08:45:53 <dom> maxf: errorCallback in send should be optional
08:46:30 <danielcoloma> Present+ Daniel_Coloma
08:47:25 <marengo> darobin: we keep timestamp as it is, it doesn't keep timezone information
08:47:30 <dom> robin: probably less of a problem that Message.timestamp loses timezone info; we can move to TimezonedDate() if we get define that
08:48:29 <marengo> dom: is timestamp referred to creation or send/receive time?
08:48:44 <marengo> bryan: could it be updated to the last event of the lifecycle?
08:49:49 <marengo> dom: normally if you receive an email you only can see when you received it, not when it was sent
08:51:54 <dom> s/you received it/it was sent/
08:52:02 <dom> s/when it was sent/when you received it/
08:52:15 <dom> ACTION: maxf to replace Message.timestamp with Message.sent and Message.received
08:52:15 <trackbot> Created ACTION-134 - Replace Message.timestamp with Message.sent and Message.received [on Max Froumentin - due 2010-03-25].
08:52:43 <marengo> richt: SuccessCallback isn't defined
08:53:58 <marengo> maxf: what do we need for successCB?
08:54:20 <marengo> darobin: it could be just a function() object [see File API]
08:54:52 <marengo> richt: in other APIs we return the updated (server-verified) object 
08:55:57 <marengo> maxf: this is a design pattern, it should be applied to other apis as well
08:57:04 <marengo> dom: let's keep it simple for v1
08:58:50 <dom> ACTION-113: also check that "empty" callbacks should be described as Function
08:58:50 <trackbot> ACTION-113 Propose a checklist of points to verify before LC for APIs, including REST-ful, minimization, policy-binding notes added
08:58:52 <marengo> maxf: in this case we don't need to receive a Message object back
08:59:06 <marengo> ... there are no use cases for it
08:59:08 <richt> ACTION: Summarize the SuccessCallback patterns and use cases for each method (i.e. use Function or SuccessCallback(Message message)) 
08:59:08 <trackbot> Sorry, couldn't find user - Summarize
08:59:16 <richt> ACTION: richt to summarize the SuccessCallback patterns and use cases for each method (i.e. use Function or SuccessCallback(Message message)) 
08:59:16 <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].
08:59:26 <dom> ACTION: maxf to change message callbacks to be of type Function
08:59:26 <trackbot> Created ACTION-136 - Change message callbacks to be of type Function [on Max Froumentin - due 2010-03-25].
08:59:56 <marengo> maxf: MessageProperties interface has the usual fields that are found in the 3 types we considered
09:00:20 <marengo> ... do we have sequences or arrays?
09:00:36 <dom> ACTION-113: also check usage of Array vs sequences
09:00:37 <trackbot> ACTION-113 Propose a checklist of points to verify before LC for APIs, including REST-ful, minimization, policy-binding notes added
09:00:57 <dom> -> http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence WebIDL Sequences
09:01:03 <dom> -> http://dev.w3.org/2006/webapi/WebIDL/#idl-array WebIDL Arrays
09:01:47 <marengo> bryan: so there's multiple distinct "to:" addresses
09:02:40 <marengo> ACTION: maxf to change sequences into arrays
09:02:40 <trackbot> Created ACTION-137 - Change sequences into arrays [on Max Froumentin - due 2010-03-25].
09:03:14 <marengo> darobin: attachment should be a list of blobs
09:04:10 <darobin> ACTION: Max to change array of DOMString attachments to array of Blobs
09:04:10 <trackbot> Created ACTION-138 - Change array of DOMString attachments to array of Blobs [on Max Froumentin - due 2010-03-25].
09:06:19 <fjh> fjh has joined #dap
09:06:28 <fjh> zakim, who is here?
09:06:28 <Zakim> On the phone I see Ruth_Vazquez (muted), DAP-In-Prague
09:06:29 <Zakim> On IRC I see fjh, jmarting, danielcoloma, ingmar, aguillou, richt, bryan, darobin, AnssiK, Kangchan, Seungyun, LauraA, JohnsonW, Zakim, RRSAgent, wonsuk, drogersuk, marengo,
09:06:32 <marengo> maxf: section 7: can it be removed?
09:06:32 <Zakim> ... RuthVazquez, blassey, Marcos, ilkka, trackbot, dom
09:07:20 <Kangchan> Present+ Kangchan_Lee
09:07:53 <marengo> ... section 8: it shouldn't say we support multiple accounts at the API level
09:08:42 <marengo> richt: should we support a subscribe() targeted to just one account?
09:09:05 <marengo> darobin: then there's a need to be able to enumerate accounts, it gets complicated
09:11:15 <marengo> darobin: what happens when you set an attribute which is not supported by the type? (Eg. attachment for SMS)
09:12:04 <marengo> .. we should re-write that normative statement (section 5 - supported messaging types)
09:12:24 <marengo> ACTION: maxf to fix section 5 "supported messaging types"
09:12:24 <trackbot> Created ACTION-139 - Fix section 5 "supported messaging types" [on Max Froumentin - due 2010-03-25].
09:13:22 <marengo> ilkka: attachments - how do you know the mimetype if it's a blob?
09:14:01 <marengo> darobin: we should use a File array
09:14:22 <fjh> fjh has joined #dap
09:14:29 <marengo> RESOLUTION: multiple account management is left to the UI
09:14:38 <dom> ACTION: Maxf to turn array of paths into array of files for attachments in Messaging API
09:14:38 <trackbot> Created ACTION-140 - Turn array of paths into array of files for attachments in Messaging API [on Max Froumentin - due 2010-03-25].
09:16:22 <marengo> bryan: "from" field should not be settable
09:16:42 <dom> close ACTION-138
09:16:42 <trackbot> ACTION-138 Change array of DOMString attachments to array of Blobs closed
09:16:43 <marengo> ACTION: maxf to update the spec to make "from" field not writable
09:16:43 <trackbot> Created ACTION-141 - Update the spec to make "from" field not writable [on Max Froumentin - due 2010-03-25].
09:16:48 <dom> ACTION-138: overtaken by ACTION-140
09:16:48 <trackbot> ACTION-138 Change array of DOMString attachments to array of Blobs notes added
09:17:59 <marengo> richt: when is "from:" set? at creation time?
09:18:13 <marengo> dom: at send() time
09:19:51 <dom> dom: leaking the From is probably not a good idea
09:20:01 <dom> ... might not want to share my phone number or email with the app/site
09:21:58 <marengo> bryan: does send() popup an UI which allows the user to review the message?
09:22:16 <marengo> .. and does the UI allow to select a default account for such operation?
09:23:42 <dom> richt: should we have two separate interfaces for Incoming and Outgoing messages?
09:23:50 <dom> dom: with different readonly properties too
09:23:59 <dom> richt: would distinguish From in Incoming and Outgoing
09:24:07 <dom> dom: and bcc would also be different
09:24:17 <dom> maxf: I'll define two types and see what it looks like
09:24:21 <richt> From would be available in incoming (read-only) but not settable or readable in outgoing
09:24:34 <dom> ACTION: maxf to propose two interfaces Outgoing and Incoming messages for messaging API
09:24:34 <trackbot> Created ACTION-142 - Propose two interfaces Outgoing and Incoming messages for messaging API [on Max Froumentin - due 2010-03-25].
09:25:09 <fjh> fjh has joined #dap
09:25:22 <fjh> zakim, who is here
09:25:22 <Zakim> fjh, you need to end that query with '?'
09:25:27 <fjh> zakim, who is here?
09:25:27 <Zakim> On the phone I see Ruth_Vazquez (muted), DAP-In-Prague
09:25:28 <dom> PROPOSED RESOLUTION: Publish messaging API as FPWD once actions items are implemented
09:25:29 <Zakim> On IRC I see fjh, jmarting, danielcoloma, ingmar, aguillou, richt, bryan, darobin, AnssiK, Kangchan, Seungyun, LauraA, JohnsonW, Zakim, RRSAgent, wonsuk, drogersuk, marengo,
09:25:32 <Zakim> ... RuthVazquez, blassey, Marcos, ilkka, trackbot, dom
09:25:44 <marengo> no objections
09:25:59 <marengo> RESOLUTION: Publish messaging API as FPWD once actions items are implemented
09:26:24 <marengo> bryan: what's the resolution about filters
09:26:39 <marengo> maxf: we'll look at the BONDI proposal
09:27:42 <marengo> AnssiK: section 6.3.2 mentions Outgoing messaging folder. it should be rephrased to state that a UI will allow to choose the folder
09:28:52 <AnssiK> s/folder/account/
09:29:09 <marengo> Topic: Policy/Privacy/Security
09:29:19 <fjh> why not say, that the message has been sent
09:29:39 <fjh> Topic: Gallery
09:30:51 <marengo> -> http://dev.w3.org/2009/dap/gallery/ the Gallery API
09:31:27 <fjh> s/<marengo> Topic: Policy\/Privacy\/Security//
09:31:30 <Zakim> -Ruth_Vazquez
09:31:48 <marengo> wonsuk: the spec is inspired by the BONDI spec
09:33:13 <marengo> .. section 2.1 more examples are needed
09:33:48 <marengo> .. [describes the 2.1 usage example]
09:35:34 <dom> -> http://lists.w3.org/Archives/Member/member-device-apis/2010Mar/0001.html Request for review of MAWG "API for Media Resource"
09:35:54 <marengo> .. section 3 is about security & privacy 
09:36:14 <marengo> darobin: there will be an external document, it will be referred here
09:37:08 <marengo> .. moves to section 4
09:38:16 <richt> Gallery API - get(..) vs find(..) ??
09:38:23 <marengo> .. galleries interface. getGalleries() offers access to the Media Galleries
09:39:02 <marengo> .. [describes gallery interface]
09:41:17 <marengo> .. GalleryProperties contains details about a specific Gallery
09:43:40 <marengo> richt: GallerySuccessCB can be a function object
09:45:52 <marengo> AnssiK: it might be beneficial to pass the object we're working on to the callback
09:46:10 <maxf> maxf has joined #dap
09:47:21 <marengo> aguillou: can you add/remove objects from a gallery?
09:47:58 <marengo> wonsuk: yes, such methods will be added
09:48:49 <marengo> richt: what's open() actually doing
09:49:25 <marengo> wonsuk: it could trigger some memory managerment options for allocating resources
09:50:28 <marengo> AnssiK: open() should be in its own interface, and be called synchronously
09:51:06 <marengo> dom: do we want an open() or a find()?
09:51:47 <marengo> .. a find() with parameters for limiting the number of items
09:54:21 <Zakim> -DAP-In-Prague
09:54:23 <Zakim> UW_DAP(F2F)3:30AM has ended
09:54:25 <Zakim> Attendees were Ruth_Vazquez, DAP-In-Prague
09:55:00 <marengo> AnssiK: can we reuse something from MAWG?
09:55:42 <marengo> wonsuk: it support 20+ media types
09:57:47 <marengo> AnssiK: can we also layer something on the File API
10:00:21 <fjh_> fjh_ has joined #dap
10:00:24 <marengo> bryan: the delta is the access to meta-data
10:01:17 <marengo> AnssiK: what has been the implementation experience in bondi?
10:01:28 <marengo> ... any feedback?
10:02:38 <marengo> AnssiK: I'll send my comments on the list, and would appreciate some feedback from BONDI
10:02:40 <richt> latest BONDI gallery spec: http://bondi01.obe.access-company.com/1_1_5179_145/gallery.html
10:03:08 <marengo> ACTION: AnssiK to provide feedback on the list
10:03:08 <trackbot> Sorry, couldn't find user - AnssiK
10:03:27 <dom> ACTION: Anssi to provide feedback on the list on Gallery API
10:03:27 <trackbot> Created ACTION-143 - Provide feedback on the list on Gallery API [on Anssi Kostiainen - due 2010-03-25].
10:03:29 <richt> BONDI Gallery demo: http://bondi01.obe.access-company.com/1_1_5179_145/gallery.html#ifGallery
10:05:05 <marengo> wonsuk: goes back to Gallery interface (changeView method)
10:05:52 <marengo> .. there is a getMediaObject for retrieving a media object by id
10:06:18 <marengo> .. GalleryProperties interface contains metadata about the gallery
10:07:14 <marengo> .. MediaObject IF is missing some functions (add, update, find, delete) which will be defined soon
10:08:48 <marengo> .. MediaObjectProperties IF should inherit something from MAWG
10:09:04 <dom> -> http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100309/ API for Media Resource 1.0
10:10:41 <marengo> bryan: [API for Media Resource] spec is intended to define a common set of attributes which are common to all formats
10:11:02 <marengo> .. we should try to use a consistent set or properties
10:11:15 <dom> -> http://www.w3.org/TR/mediaont-10/#property-mapping-table Mapping tables of Ontology for Media Resource
10:11:58 <dom> -> http://www.w3.org/TR/mediaont-10/iTunes.html Mapping to iTunes format
10:13:28 <fjh> fjh has joined #dap
10:15:45 <marengo> wonsuk: ViewType IF describes how a gallery is displayed
10:16:39 <dom> [ViewType really is a filter/sorter interface; it needs to be renamed in something easier to relate to]
10:16:58 <marengo> .. ordering criteria, date filters
10:18:22 <marengo> AnssiK: there could be a sort() method in Gallery
10:18:48 <marengo> bryan: what about random filtering (e.g. shuffle)
10:19:16 <maxf> maxf has joined #dap
10:19:55 <marengo> AnssiK: it could be done by the app, if there's easy access to metadata
10:20:53 <marengo> darobin: we're running out of time
10:21:36 <marengo> bryan: let's align this with other filters in DAP APIs (eg. media item file size)
10:21:46 <fjh> zakim, who is here?
10:21:46 <Zakim> apparently UW_DAP(F2F)3:30AM has ended, fjh
10:21:47 <Zakim> On IRC I see maxf, fjh, jmarting, danielcoloma, ingmar, aguillou, richt, bryan, darobin, AnssiK, Kangchan, Seungyun, LauraA, JohnsonW, Zakim, RRSAgent, wonsuk, drogersuk, marengo,
10:21:49 <Zakim> ... RuthVazquez, blassey, Marcos, ilkka, trackbot, dom
10:22:58 <marengo> drogersuk: there's some basic filter in ViewType
10:23:24 <marengo> darobin: yes, it should be consistent through all the apis
10:25:42 <marengo> wonsuk: there are no use cases in the spec, yet
10:25:56 <marengo> .. that's all for gallery
10:26:10 <marengo> [5 minutes break]
10:27:23 <danielcoloma> danielcoloma has left #dap
10:30:59 <maxf> maxf has left #dap
10:31:21 <maxf> maxf has joined #dap
10:33:41 <dom> RRSAgent, draft minutes
10:33:41 <RRSAgent> I have made the request to generate http://www.w3.org/2010/03/18-dap-minutes.html dom
10:35:19 <dom> s/<marengo> ->/<marengo_scribe> ->/g
10:35:21 <dom> RRSAgent, draft minutes
10:35:21 <RRSAgent> I have made the request to generate http://www.w3.org/2010/03/18-dap-minutes.html dom
10:36:05 <marengo> Topic: Policy/Privacy/Security
10:36:31 <marengo> -> http://dev.w3.org/2009/dap/privacy-reqs/ Privacy Reqs draft
10:36:52 <marengo> fjh: goes through the updated version
10:37:12 <marengo> ... section 6: privacy requirements
10:37:28 <marengo> ... mentions minimization
10:37:47 <marengo> ... replicates the table we designed
10:37:59 <marengo> ... this could go FPWD
10:39:06 <dom> ACTION: Dom to take an editorial pass at privacy-reqs
10:39:06 <trackbot> Created ACTION-144 - Take an editorial pass at privacy-reqs [on Dominique Hazaël-Massieux - due 2010-03-25].
10:40:28 <marengo> -> http://dev.w3.org/2009/dap/policy-reqs/ Policy Reqs draft
10:40:52 <marengo> fjh: scrolls the doc
10:41:27 <marengo> .. section 8 use cases
10:41:32 <marengo> .. section 9: requirements
10:42:39 <marengo> .. concerned about the next steps (section 9.4.1, 9.4.2)
10:43:24 <maxf> maxf has left #dap
10:43:54 <maxf> maxf has joined #dap
10:45:07 <marengo> ACTION: bryan to provide an architectural flow for Policy Reqs
10:45:08 <trackbot> Created ACTION-145 - Provide an architectural flow for Policy Reqs [on Bryan Sullivan - due 2010-03-25].
10:45:49 <marengo> LauraA: what's the relation with the joining of the BONDI and Nokia proposals (it is ongoing work)
10:46:02 <dom> [I think we would better served with use cases than requirements for policy]
10:49:20 <dom> Dave: the best way is probably to go ahead with the policy proposal
10:49:31 <dom> ... I think we'll find a common ground for the trust domains questions
10:50:10 <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
10:50:41 <dom> Frederick: the threats considerations should also address the security questions
10:51:58 <dom> ... what about sending a CfC for privacy-reqs as we agreed?
10:52:38 <dom> ACTION: Frederick to send a CfC on privacy-reqs when Dom is done with edits
10:52:39 <trackbot> Created ACTION-146 - Send a CfC on privacy-reqs when Dom is done with edits [on Frederick Hirsch - due 2010-03-25].
10:54:54 <dom> Topic: other APIs
10:55:09 <dom> David: for Commlog, in BONDI, we are moving into a more general telephony API
10:55:43 <darobin> AnssiK: what's the use case for receiving a call programmatically
10:55:54 <darobin> Bryan: customer care widget
10:56:31 <darobin> ... David's point is that the API has changed to only do logs, but the calls are in the messaging API
10:56:37 <darobin> David: it's cleaner
10:56:56 <darobin> ... you might want to consider it, but I realise it's not in the charter
10:57:18 <darobin> Bryan: in principle it's the ability to know abotu call events
10:57:43 <darobin> FJH: does telephony expand the scope and amount of work
10:57:58 <darobin> ... so it's the same functionality in a different place?
10:58:47 <darobin> David: we have a commslog that does logging, then later we'll extend to calls — but that's out of charter
10:58:59 <dom> s/we have/BONDI has/
10:59:08 <dom> s/of charter/of DAP charter/
10:59:32 <darobin> David: if you were to drop Commslog we wouldn't be against it, so long as its information goes somewhere
11:09:21 <Kangchan> Kangchan has joined #dap
11:49:25 <Marcos_> Marcos_ has joined #dap
11:54:50 <Marcos> Marcos has joined #dap
12:01:47 <Marcos> Marcos has joined #dap
12:06:09 <Marcos> Marcos has joined #dap
12:20:37 <drogersuk> drogersuk has joined #dap
12:24:58 <darobin> darobin has joined #dap
12:26:38 <wonsuk> wonsuk has joined #dap
12:27:03 <fjh> fjh has joined #dap
12:30:17 <Zakim> Zakim has left #dap
12:35:49 <tlr> tlr has joined #dap
12:41:45 <fjh> zakim, pick a victim
12:41:56 <Zakim> Zakim has joined #dap
12:42:00 <fjh> zakim, victim please?
12:42:00 <Zakim> I don't understand your question, fjh.
12:42:00 <dom> zakim, pick a victim
12:42:02 <Zakim> sorry, dom, I don't know what conference this is
12:42:06 <dom> zakim, this is DAP
12:42:06 <Zakim> dom, I see UW_DAP(F2F)3:30AM in the schedule but not yet started.  Perhaps you mean "this will be DAP".
12:42:07 <dom> zakim, pick a victim
12:42:08 <Zakim> sorry, dom, I don't know what conference this is
12:42:13 <dom> zakim, this will be DAP
12:42:13 <Zakim> ok, dom; I see UW_DAP(F2F)3:30AM scheduled to start 312 minutes ago
12:42:14 <dom> zakim, pick a victim
12:42:15 <Zakim> sorry, dom, I don't know what conference this is
12:42:25 <dom> Zakim, who's your daddy?
12:42:25 <Zakim> Ralph is taking good care of me but you all are my family, dom
12:42:33 <fjh> zakim, xyzzy
12:42:33 <Zakim> I don't understand 'xyzzy', fjh
12:42:39 <fjh> xyzzy
12:42:44 <fjh> s/xyzzy//
12:42:53 <fjh> s/zakim, xyzzy//
12:43:13 <richt> zakim, good job :-)
12:43:13 <Zakim> I'm glad that smiley is there, richt
12:43:31 <dom> trackbot, you are wrong
12:43:31 <trackbot> Sorry, dom, I don't understand 'trackbot, you are wrong'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
12:43:45 <dom> trackbot, thanks
12:43:45 <trackbot> You are most welcome, dom
12:44:01 <aguillou> aguillou has joined #dap
12:44:10 <aguillou> Present+Aurelien_Guillou
12:44:41 <darobin> Topic: Charter
12:46:37 <darobin> FH: it's a tight schedule
12:46:50 <darobin> ... it'll take at least a quarter to exit LC+CR
12:47:02 <darobin> ... that means we have to have things done soon
12:47:27 <darobin> Dom: one of the reason we have the end date is because people are eagerly awaiting the result
12:47:38 <darobin> ... our work is more relevant if it finishes on time
12:47:47 <darobin> FH: we've agreed on where we're going
12:47:54 <darobin> .... things are well on their way
12:48:22 <darobin> ... for 10Q2-Q3 we have to get everything on Rec track
12:48:39 <darobin> ... [explains process really, really fast]
12:49:23 <darobin> ... you don't want to wait until CR before you do some interop testing
12:49:49 <darobin> ... if we could avoid multiple LC it's nice
12:49:55 <darobin> ... after CR, PR
12:50:21 <darobin> ... next year needs to be all about CR
12:50:29 <darobin> .... so we have to finish LCs this year
12:50:49 <bsulliva> bsulliva has joined #dap
12:51:07 <darobin> ?
12:51:11 <bsulliva> scribenick: bsulliva
12:52:39 <bsulliva> fjh: gives an overview of the status, available on the home page
12:54:04 <bsulliva> fjh: tasks API, why are we waiting, is this simple with input contributions
12:54:15 <bsulliva> dom: it may be as complicated as calendar
12:54:25 <bsulliva> fjh: wait for calendar and layer it on top?
12:54:40 <bsulliva> fjh: can we draft the non-recurrent stuff first?
12:54:51 <bsulliva> dom: we need at least an editor volunteer to get started
12:55:09 <bsulliva> fjh: what happens if we get no volunteers
12:55:49 <bsulliva> drogersuk: we can query the BONDI supporters that are DAP members who may be able to provide input
12:56:05 <dom> ACTION: David to look for an editor for the Tasks API
12:56:05 <trackbot> Created ACTION-147 - Look for an editor for the Tasks API [on David Rogers - due 2010-03-25].
12:56:31 <bsulliva> fjh: if we know early, we will be better able to deal with the options
12:56:45 <bsulliva> richt: calendar will help with the issues
12:57:14 <bsulliva> fjh: applauncher, we need an editor
12:57:29 <bsulliva> wonsuk: volunteers as editor
12:58:10 <bsulliva> bsulliva: I can provide input
12:58:26 <bsulliva> wonsuk: 4-6 weeks to get a draft started
12:58:47 <bsulliva> fjh: appconfig, we dropped this and have nothing more to do
12:59:07 <bsulliva> fjh: user interaction, to webapps?
12:59:55 <bsulliva> bsulliva: the modify the user interface e.g. menus are not covered by window modes
13:00:11 <bsulliva> fjh: do we need to do those at this time?
13:00:31 <bsulliva> drogersuk: this should be done in V1
13:00:46 <bsulliva> fjh: anssi suggested this was covered by the webapps API's
13:01:41 <bsulliva> bsulliva: we need someone to survey webapps to determine the gaps
13:01:44 <dom> -> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0207.html Anssi's email on user interaction API requirements
13:01:56 <AnssiK> -> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0212.html
13:02:08 <bsulliva> anssi: we have some options in HTML5 spec re menu controls
13:03:05 <Marcos> Marcos has joined #dap
13:03:28 <bsulliva> fjh: is someone familiar with BONDI able to decide if we have filled the gaps already?
13:03:31 <AnssiK> -> http://www.w3.org/TR/html5/interactive-elements.html#menus
13:03:46 <shepazu> shepazu has joined #dap
13:03:49 <bsulliva> bsulliva: I will take this one on
13:04:16 <dom> ACTION: Bryan to compare user interaction input with what already available in HTML5 / WebApps
13:04:16 <trackbot> Created ACTION-148 - Compare user interaction input with what already available in HTML5 / WebApps [on Bryan Sullivan - due 2010-03-25].
13:04:32 <bsulliva> darobin: will review what Bryan writes
13:04:58 <bsulliva> fjh: on commlog, what are the next steps
13:05:48 <fjh> david suggests that part goes into messaging, and commlog might be renamed telephony
13:06:00 <bsulliva> 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 
13:06:28 <bsulliva> drogersuk: a suggestion is to pull the messaging parts out and defer the rest to a telephony API for V2
13:06:55 <bsulliva> anssi: you can use commlog to find the people you want to interact with
13:07:16 <bsulliva> richt: we could take the approach of a generic log
13:07:51 <bsulliva> drogersuk: we would be creating new concepts there, not basing that upon established work
13:08:52 <bsulliva> dom: commlog is more like accessing your mailbox
13:09:27 <bsulliva> fjh: who can help with the commlog draft?
13:09:49 <bsulliva> dom: we could add the read/log functions to the messaging API
13:10:14 <bsulliva> drogersuk: we have an action to review the messaging input from BONDI for guidance on that
13:11:03 <bsulliva> drogersuk: there are use cases where call log is useful
13:11:50 <bsulliva> bsulliva: we could just call what's left as the telephony API
13:12:17 <bsulliva> fjh: the proposal is for messaging to have the messaging log functions
13:13:17 <bsulliva> drogersuk: we realized in BONDI that the logs should be associated with the feature
13:14:00 <fjh> bsullivan notes messaging is a feature set, message log is a feature
13:15:15 <bsulliva> 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)
13:15:53 <bsulliva> richt: are you saying they should be common, as a distinct messaging API with log features makes more sense
13:17:26 <bsulliva> 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
13:17:56 <bsulliva> dom: communication is a common function regardless of the communication type
13:18:41 <bsulliva> fjh: we said in the privacy discussion that you need access to the logs
13:18:45 <tlr> tlr has joined #dap
13:19:01 <bsulliva> dom: we maybe need an issue to continue this
13:19:21 <dom> ISSUE: should Communication Logs be part of the messaging API or part of a telephony API?
13:19:21 <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 .
13:20:20 <dom> ACTION: David to summarize discussions on BONDI regarding Communication Log/messaging/Telephony API
13:20:20 <trackbot> Created ACTION-149 - Summarize discussions on BONDI regarding Communication Log/messaging/Telephony API [on David Rogers - due 2010-03-25].
13:21:16 <bsulliva> fjh: re other deliverables, for interoper there is work to make sure things work well, so they are better prepared for the formal call 
13:21:30 <bsulliva> fjh: not sure the nature of DAP API's fit that model
13:21:42 <RuthVazquez> RuthVazquez has joined #dap
13:22:28 <bsulliva> fjh: the call for implementations at CR can be prefaced with interop testing within the group
13:22:58 <bsulliva> fjh: that is easier if you have interop testing in advance
13:23:24 <bsulliva> fjh: do we have enough vendors here to do that pre-interop, and who wtites test cases?
13:23:37 <bsulliva> fjh: who will run them?
13:23:48 <bsulliva> darobin: we will do both
13:24:40 <bsulliva> drogersuk: a lot more than two interoperable implementations based upon BONDI will likely implement the DAP API's
13:24:54 <bsulliva> anssi: does the approach used in webapps work for us?
13:25:02 <bsulliva> fjh: the real question is who?
13:26:38 <arve> arve has joined #dap
13:27:50 <bsulliva> seungyun: is it possible to base the testing on prototypes of web runtimes?
13:27:54 <fjh> we should confirm informal interop in June
13:28:11 <bsulliva> dom: we need at least two browsers and web runtimes
13:28:17 <fjh> dom notes will need two browser implementations plus 2 web runtime
13:28:47 <bsulliva> fjh: a virtual interop may make sense
13:29:17 <dom> s/we need/I think we should require/
13:30:09 <bsulliva> bsulliva: maybe some of the BONDI test framework would be useful to DAP
13:30:31 <dom> ACTION: David to send BONDI experience with testing for device APIs
13:30:31 <trackbot> Created ACTION-150 - Send BONDI experience with testing for device APIs [on David Rogers - due 2010-03-25].
13:31:04 <bsulliva> drogersuk: there might be 30 or more implementations to consider in this case
13:31:41 <bsulliva> drogersuk: we would like to follow similar approaches as Marcos did on the widgets P&C
13:32:13 <bsulliva> fjh: testable assertions may an issue for policy
13:32:38 <bsulliva> fjh: getting started on this by July should give us time
13:33:19 <bsulliva> fjh: re liaisons, do we need to worry about accessibility in API's?
13:33:42 <bsulliva> darobin: have no concerns that come to mind
13:34:32 <bsulliva> bsulliva: requiring user interaction is a concern for usability
13:35:27 <bsulliva> fjh: anything else?
13:35:36 <dom> -> http://www.w3.org/2009/dap/wiki/FutureWork Future Work for DAP
13:35:49 <bsulliva> drogersuk: do we have a wish list for V2?
13:37:08 <bsulliva> fjh: should provide a heads up if it might inform our current work
13:37:25 <bsulliva> darobin: AOB?
13:37:41 <dom> RESOLUTION: Thanks Jirka for hosting us!
13:37:55 <richt> Thanks!
13:37:58 <bsulliva> fjh: once, twice, adjourned
13:38:06 <dom> RRSAgent, draft minutes
13:38:06 <RRSAgent> I have made the request to generate http://www.w3.org/2010/03/18-dap-minutes.html dom
13:39:02 <bsulliva> bsulliva has left #dap
13:42:09 <drogersuk> drogersuk has joined #dap
15:01:11 <Zakim> Zakim has left #dap