IRC log of dap on 2010-03-18

Timestamps are in UTC.

08:03:31 [RRSAgent]
RRSAgent has joined #dap
08:03:31 [RRSAgent]
logging to
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:
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]
-> 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]
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]
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
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]
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:
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]
-> 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]
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]
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]
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]
-> WebIDL Sequences
09:01:03 [dom]
-> 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]
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]
-> the Gallery API
09:31:27 [fjh]
s/<marengo> Topic: Policy\/Privacy\/Security//
09:31:30 [Zakim]
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]
-> 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]
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:
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:
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]
-> 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]
-> Mapping tables of Ontology for Media Resource
10:11:58 [dom]
-> 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 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 dom
10:36:05 [marengo]
Topic: Policy/Privacy/Security
10:36:31 [marengo]
-> 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]
-> 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]
12:42:44 [fjh]
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 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]
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]
-> Anssi's email on user interaction API requirements
13:01:56 [AnssiK]
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]
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 .
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]
-> 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]
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 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