IRC log of dap on 2011-03-16

Timestamps are in UTC.

00:02:03 [RRSAgent]
RRSAgent has joined #dap
00:02:03 [RRSAgent]
logging to
00:02:05 [trackbot]
RRSAgent, make logs world
00:02:05 [Zakim]
Zakim has joined #dap
00:02:07 [trackbot]
Zakim, this will be DAP
00:02:07 [Zakim]
ok, trackbot; I see UW_DAP(DAPWGF2F)7:00PM scheduled to start 62 minutes ago
00:02:08 [trackbot]
Meeting: Device APIs and Policy Working Group Teleconference
00:02:08 [trackbot]
Date: 15 March 2011
00:02:14 [soonho]
Present+ Soonho_Lee
00:02:34 [dom]
Present+ Dominique_Hazael-Massieux
00:02:49 [soonho]
Sorry for not attending meeting in this morning.
00:03:16 [soonho]
I will be there afternoon.
00:03:30 [shan]
shan has joined #dap
00:03:52 [shan]
Present+ Soonbo_Han
00:04:04 [marengo]
marengo has joined #dap
00:04:18 [bryan_sullivan]
bryan_sullivan has joined #dap
00:04:28 [bryan_sullivan]
present+ bryan_sullivan
00:04:32 [Zakim]
UW_DAP(DAPWGF2F)7:00PM has now started
00:04:39 [Zakim]
00:04:49 [Kangchan]
Kangchan has joined #dap
00:04:50 [dom]
Zakim, ??P2 is DAPWG
00:04:50 [Zakim]
+DAPWG; got it
00:05:01 [marengo]
Present+ Marco_Marengo
00:05:37 [minkyo]
minkyo has joined #dap
00:06:06 [Zakim]
00:07:10 [donghyun_kang]
donghyun_kang has joined #DAP
00:08:08 [fjh]
fjh has joined #dap
00:08:37 [fjh]
trackbot-ng, start telecon
00:08:40 [trackbot]
RRSAgent, make logs world
00:08:42 [trackbot]
Zakim, this will be DAP
00:08:42 [Zakim]
ok, trackbot, I see UW_DAP(DAPWGF2F)7:00PM already started
00:08:43 [trackbot]
Meeting: Device APIs and Policy Working Group Teleconference
00:08:43 [trackbot]
Date: 15 March 2011
00:08:48 [dom]
RRSAgent, this meeting span midnight
00:08:48 [RRSAgent]
I'm logging. I don't understand 'this meeting span midnight', dom. Try /msg RRSAgent help
00:08:57 [dom]
RRSAgent, this meeting spans midnight
00:09:04 [fjh]
Chair: Robin_Berjon, Frederick_Hirsch
00:09:14 [AnssiK]
AnssiK has joined #dap
00:09:21 [Liao_Jun]
Liao_Jun has joined #dap
00:09:23 [donghyun_kang]
Present+ DongHyun_Kang
00:09:25 [fjh]
Present+ Robin_Berjon, Frederick_Hirsch
00:09:32 [Chen]
Chen has joined #dap
00:09:33 [sungok]
sungok has joined #dap
00:09:40 [Liao_Jun]
Present+ Jun_Liao
00:09:55 [ktaklee]
ktaklee has joined #dap
00:09:58 [Zakim]
00:10:01 [fjh]
00:10:03 [Chen_Bo]
Chen_Bo has joined #dap
00:10:06 [ktaklee]
Present+ Kyung-Tak_Lee
00:10:07 [darobin]
darobin has joined #dap
00:10:19 [AnssiK]
zakim, +??P4 is AnssiK
00:10:19 [Zakim]
sorry, AnssiK, I do not recognize a party named '+??P4'
00:10:20 [Chen_Bo]
Present+ Bo_Chen
00:10:26 [homata__]
homata__ has joined #dap
00:10:26 [Kangchan]
present+ Kangchan_Lee
00:10:28 [AnssiK]
zakim, ??P4 is AnssiK
00:10:28 [Zakim]
+AnssiK; got it
00:10:34 [AnssiK]
Present+ Anssi_Kostiainen
00:10:38 [fjh]
ScribeNick: bryan
00:10:47 [BJ]
BJ has joined #dap
00:10:47 [fjh]
ScribeNick: bryan_sullivan
00:11:27 [fjh]
Topic: Admin
00:11:29 [minkyo]
Present+ Minkyo_in
00:12:55 [AnssiK]
00:12:59 [Suresh]
Can we swap the morning and afternoon items in today's agenda?
00:13:10 [sungok]
Present+ sungok_you
00:13:24 [dom]
Suresh, which items specifically would you like to switch?
00:13:24 [fjh]
agenda bashing...
00:13:41 [wuj]
wuj has joined #dap
00:14:16 [Liang]
Liang has joined #dap
00:15:04 [minkyo]
minkyo has left #dap
00:15:26 [AnssiK]
zakim, who is here?
00:15:26 [Zakim]
On the phone I see DAPWG, Suresh, AnssiK
00:15:27 [Zakim]
On IRC I see Liang, wuj, BJ, homata__, darobin, Chen_Bo, ktaklee, sungok, Liao_Jun, AnssiK, fjh, donghyun_kang, Kangchan, bryan_sullivan, marengo, shan, Zakim, RRSAgent, soonho,
00:15:29 [Zakim]
... Suresh, homata_, richt, ilkka, lgombos, ingmar, dom, trackbot
00:18:14 [bryan_sullivan]
topic: sysinfo and sensors
00:18:34 [Zakim]
+ +1.781.534.aaaa
00:18:45 [lgombos]
Present+ Laszlo_Gombos
00:18:57 [fjh]
zakim, aaaa is laszlo
00:18:57 [Zakim]
+laszlo; got it
00:19:02 [bryan_sullivan]
bryan: is this discussion in context of breaking sysinfo into pieces?
00:19:02 [dom]
Bryan: 1st question: are we tackling this in context of new strategy for sysinfo with breaking it apart?
00:19:10 [bryan_sullivan]
dom: where are we going and how
00:19:21 [dom]
-> SysInfo editors draft
00:19:39 [Suresh]
Did we talk about a vocabulary approach, yesterday?
00:20:46 [fjh]
00:20:52 [dom]
we did talk about how sysinfo relates to vocabulary-based approaches
00:20:58 [bryan_sullivan]
bryan: what are the key functional blocks to consider as discrete APIs?
00:21:15 [minkyo]
minkyo has joined #dap
00:21:49 [bryan_sullivan]
bryan: how do the info access methods also influence the split?
00:22:17 [Suresh]
To me it would be good to split the properties into static (display size, etc) and dynamic (connecttivity, etc)
00:22:38 [bryan_sullivan]
dom: there are two parts, accessing device characteristics and monitoring dynamic properties
00:23:12 [Suresh]
For static properties, we could define a very simple getPropXX () type API and for dynamic APIs decide how we want to proceed
00:24:17 [AnssiK]
the current SystemInfo API draft is almost as extensive as /proc (procfs) in UNIX-like OSs
00:24:26 [bryan_sullivan]
bryan: are the properties to be split per static and dynamic, or by the functional group e.g. connection info
00:24:54 [AnssiK]
00:24:57 [bryan_sullivan]
dom: the first step is to see what can be split out, e.g. connection info, and get editor volunteers
00:26:24 [bryan_sullivan]
dom: suggestion to dive into the blocks, starting with the network info. this should be split out into a spec of its own
00:26:33 [bryan_sullivan]
bryan: capabilities and status?
00:27:55 [dom]
-> Rich's proposal for simple Network API
00:28:32 [AnssiK]
+1 for the Network
00:28:52 [bryan_sullivan]
dom: the next step is to find an editor for the network info API
00:28:53 [lgombos]
I plan to take an iteration on the network part
00:29:02 [AnssiK]
Battery would be another, which IMHO should not have privacy issues
00:29:05 [dom]
-> navigator.connection in Android
00:29:32 [Suresh]
+1 to Rich's proposal
00:30:03 [Gyubong]
Gyubong has joined #dap
00:30:11 [bryan_sullivan]
dom: for the network API, richt made a proposal for the network API
00:30:15 [Gyubong]
Present+ Gyubong_Oh
00:30:16 [Suresh]
i mean we could adopt a similar style to most of the sys info properties
00:30:31 [bryan_sullivan]
dom: laslo or suresh, do you want to take this on?
00:31:58 [dom]
ACTION: Suresh to provide first draft of Network Connection API
00:31:58 [trackbot]
Created ACTION-357 - Provide first draft of Network Connection API [on Suresh Chitturi - due 2011-03-23].
00:31:59 [bryan_sullivan]
suresh: will take on the network info API
00:33:11 [bryan_sullivan]
dom: next, anssi mentioned that battery was likely simple enough re privacy and is useful. we don't have a concrete proposal, but the current content in sysinfo can be used as a start
00:33:12 [dom]
Battery status
00:33:37 [dom]
ACTION: Anssi to provide first editors draft of a Battery status API
00:33:37 [trackbot]
Created ACTION-358 - Provide first editors draft of a Battery status API [on Anssi Kostiainen - due 2011-03-23].
00:34:27 [bryan_sullivan]
dom: next was the thermometer, we could put this on the back burner
00:34:52 [bryan_sullivan]
darobin: ok to put more things on the back burner
00:35:09 [dom]
ACTION-358: Web Performance WG was interested on battery status — probably need coordination
00:35:09 [trackbot]
ACTION-358 Provide first editors draft of a Battery status API notes added
00:35:40 [Suresh]
CPU is something device vendors like to keep it to themselves
00:36:03 [dom]
CPU is candidate for backburnering
00:37:00 [bryan_sullivan]
dom: next is CPU, it is unsure whether there are strong use cases for it; could be related to performance, e.g. the Web performance group is focused on battery impacts
00:37:55 [AnssiK]
00:37:56 [bryan_sullivan]
dom: for the sensors, we have the question of a generic sensor API. Anssi sent something about what is available in android
00:37:57 [AnssiK]
00:38:42 [bryan_sullivan]
anssik: not me
00:38:54 [Chen_Bo]
Chen_Bo has joined #dap
00:39:37 [bryan_sullivan]
bryan: I can take on the sensors, but need to know what the plan is for a generic API for this
00:39:43 [dom]
Zakim, who's noisy?
00:40:00 [Zakim]
dom, listening for 14 seconds I heard sound from the following: DAPWG (90%)
00:40:09 [bryan_sullivan]
dom: sysinfo as it exists could be a start
00:40:45 [bryan_sullivan]
bryan: i can put things in documents but I am not necessarily the technical SME
00:41:21 [dom]
ACTION: Bryan to split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo
00:41:21 [trackbot]
Created ACTION-359 - Split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo [on Bryan Sullivan - due 2011-03-23].
00:41:54 [AnssiK]
navigator.platform and navigator.oscpu expose CPU-related information already today, works in Moz, Chrome, Saf at least
00:42:19 [AnssiK]
what I'm not sure is if developers are using that information
00:43:26 [bryan_sullivan]
dom: most of the other things are about static properties of the device, most re privacy have abilities re fingerprinting (building a unique identifier based upon device capabilities)
00:44:11 [Suresh]
Anssi, but that is only the OS information not info such frequency, processor info, etc
00:44:18 [AnssiK]
q+ to ask do we have a use case that is not fulfilled with the existing platform and oscpu properties on the navigator
00:44:25 [bryan_sullivan]
dom: we could start with considering which are most useful
00:45:20 [bryan_sullivan]
dom: suresh, are the static properties e.g. cameras microphones etc of interest
00:45:35 [bryan_sullivan]
suresh: can take on those
00:46:11 [dom]
ACTION: Suresh to see at possibilities of APIs for access to device characteristics
00:46:11 [trackbot]
Created ACTION-360 - See at possibilities of APIs for access to device characteristics [on Suresh Chitturi - due 2011-03-23].
00:46:55 [Suresh]
I assume device characteristics are 'read-only'?
00:47:43 [bryan_sullivan]
bryan: should we package the dynamic I/O APIs as a package?
00:48:29 [bryan_sullivan]
dom: we should consider that for each feature we want to make available rather than in the abstract
00:48:56 [AnssiK]
I heard Bryan or Suresh say something about screen related props, for existing ones, see:
00:49:08 [wonsuk]
wonsuk has joined #dap
00:49:23 [wonsuk]
Present+ Wonsuk_Lee
00:49:39 [AnssiK]
CSS OM exposes much information that is useful for developers, such as the dimensions of the viewport
00:49:59 [dom]
ACTION: Bryan to provide use cases for device characteristics access
00:49:59 [trackbot]
Created ACTION-361 - Provide use cases for device characteristics access [on Bryan Sullivan - due 2011-03-23].
00:50:00 [AnssiK]
q+ to clarify the Screen part
00:50:07 [dom]
ack AnssiK
00:50:07 [Zakim]
AnssiK, you wanted to ask do we have a use case that is not fulfilled with the existing platform and oscpu properties on the navigator and to clarify the Screen part
00:51:11 [bryan_sullivan]
bryan: I will look into the dynamic I/O properties and provide some input, as I think these are related in value to some of the sensor properties, not in terms of a common API but just to help focus what we repackage in the new APIs
00:52:14 [bryan_sullivan]
dom: CSSOM addresses a number of important characteristics from the dsplay
00:52:55 [bryan_sullivan]
bryan: would CSSOM provide a pattern for audio?
00:53:14 [bryan_sullivan]
dom: no, mostly for display characteristics
00:54:39 [bryan_sullivan]
dom: that covers a first plan for sysinfo
00:55:09 [bryan_sullivan]
bryan: what about storage?
00:55:21 [bryan_sullivan]
dom: proposed work in webapps might cover that
00:55:35 [bryan_sullivan]
darobin: unsure whether it covers all of it
00:56:05 [dom]
-> Quota API discussion in WebApps
00:56:45 [AnssiK]
00:57:52 [bryan_sullivan]
dom: suggest not to work on this given overlap with the work in webapps e.g. with filesystem
00:58:01 [dom]
dom: probably covers most of what would be useful for storage
00:59:11 [bryan_sullivan]
bryan: conceptually this is in the same ballpark as filesystem operations, e.g. to see the size of a filesystem
01:00:57 [bryan_sullivan]
kangchan: the use cases are hard to understand, in Korea there are many projects e.g. for n-screen and mobile cloud computing, and sysinfo is unique in the world providing the access to this info. We can look at the use cases and provide additional input.
01:01:08 [dom]
ACTION: Kangchan to provide use cases for sysinfo-like features
01:01:08 [trackbot]
Created ACTION-362 - Provide use cases for sysinfo-like features [on Kangchan Lee - due 2011-03-23].
01:02:33 [bryan_sullivan]
topic: messaging
01:02:36 [Kangchan]
s/the use cases are hard to understand/the use case is very helpful to understand the recommendation/
01:02:47 [Suresh]
q+ to clarify the change in direction for Messaging
01:03:04 [fjh]
ack Sureash
01:03:07 [fjh]
ack Suresh
01:03:07 [Zakim]
Suresh, you wanted to clarify the change in direction for Messaging
01:03:13 [darobin]
-> Dom's Messaging proposal
01:03:18 [fjh]
s/ack Sureash//
01:03:24 [fjh]
rrsagent, generate minutes
01:03:24 [RRSAgent]
I have made the request to generate fjh
01:03:48 [bryan_sullivan]
suresh: missed last week's discussion, if the group has agreed to simplify this, what is it based upon?
01:04:30 [Suresh]
We clearly say in the scope that the API complements the URI schemes, so this is not competing with URI schemes
01:04:33 [bryan_sullivan]
dom: the discussion last week was based upon earlier discussion that this is related to what can be done with URI schemes
01:05:08 [dom]
dom: the latest proposal I sent for messaging is feature-equivalent to the draft we have currently published as working draft
01:06:51 [Suresh]
Super simplification would not allow us to extend in the future if we were to add folder management, search, etc.
01:08:20 [wuj_]
wuj_ has joined #dap
01:09:09 [Suresh]
But is there a real concern with the current API? Why don't wait for some time to see if there are real issues with implementing as it is
01:09:46 [bryan_sullivan]
dom: re extensbility, we can consider more and mroe advancef features separately, but the majority of send message is covered by the URI scheme proposal. Creating wrappers around URI based methods can also fill the gaps.
01:10:42 [Suresh]
we also talked about the need to separate the design for different messaging technology and ease of use...
01:10:43 [bryan_sullivan]
dom: the previous proposal is not integrated well into the Web architecture
01:11:01 [fjh]
s/mroe advancef/more advanced/
01:12:01 [bryan_sullivan]
dom: the two existing proposals are mostly feature equivalent
01:12:41 [Suresh]
This is the same anaolgy we have between using HTML Media Capture and Camera
01:13:11 [fjh]
01:13:14 [bryan_sullivan]
bryan: the other use cases e.g. read/receive are not in the current API anyway, and can be considered for future work
01:15:05 [Suresh]
the point i was making was can we have the two models co-exist, URI schemes and a detailed programtic style API
01:16:01 [bryan_sullivan]
dom: implementers don't want to develop duplicate features
01:16:27 [bryan_sullivan]
dom: the stream API is significantly different from HTML media capture
01:17:05 [bryan_sullivan]
dom: even if we do consider a programmatic API eventually, that doesn't mean we need to start with it
01:17:06 [Suresh]
From ease of use, developers would want to be able to set properties than creating a URL to populate them
01:17:40 [bryan_sullivan]
dom: a start may be to update the current draft with the new proposal, and call for feedback before moving forward
01:18:04 [bryan_sullivan]
dom: having an interface to build messages is a convenience function
01:18:17 [bryan_sullivan]
darobin: libraries can do that
01:18:41 [Suresh]
relying on libaries is not the same as having a standard API
01:18:56 [Suresh]
implemented in the browser....
01:19:00 [bryan_sullivan]
dom: there are good reasons on both sides, let's put the two proposals on the table
01:19:15 [dom]
PROPOSED RESOLUTION: publish new messaging API as WD and ask for feedback (esp. from developers and implementors)
01:19:16 [darobin]
01:19:26 [Suresh]
perhpas as you suggest we should have a call for implementations
01:19:55 [fjh]
01:21:44 [dom]
RESOLUTION: publish new messaging API as WD and ask for feedback (esp. from developers and implementors)
01:21:56 [dom]
ACTION: Dom to see with Maria on how to proceed for updated messaging api draft
01:21:56 [trackbot]
Created ACTION-363 - See with Maria on how to proceed for updated messaging api draft [on Dominique Hazaël-Massieux - due 2011-03-23].
01:22:00 [Suresh]
just to summarize, we would present both the proposals and ask for feedback right>
01:22:14 [dom]
indeed, suresh
01:22:20 [Suresh]
01:22:53 [Zakim]
01:24:28 [Zakim]
01:34:00 [blassey]
blassey has joined #dap
01:57:51 [Zakim]
01:58:59 [minkyo]
minkyo has joined #dap
01:59:05 [Zakim]
01:59:17 [dom]
??P2 is DAPWG
01:59:19 [fjh]
zakim, who is here?
01:59:19 [Zakim]
On the phone I see AnssiK, laszlo, Suresh, ??P2
01:59:20 [Zakim]
On IRC I see minkyo, blassey, wuj_, wonsuk, Chen_Bo, Liang, BJ, homata__, darobin, ktaklee, sungok, AnssiK, fjh, donghyun_kang, Kangchan, bryan_sullivan, shan, Zakim, RRSAgent,
01:59:21 [dom]
Zakim, who's on the bridge
01:59:23 [Zakim]
... soonho, Suresh, homata_, richt, ilkka, lgombos, ingmar, dom, trackbot
01:59:25 [Zakim]
I don't understand 'who's on the bridge', dom
01:59:27 [dom]
Zakim, who's on the bridge?
01:59:27 [Zakim]
I don't understand your question, dom.
01:59:33 [dom]
Zakim, who's on the phone?
01:59:33 [Zakim]
On the phone I see AnssiK, laszlo, Suresh, ??P2
02:02:10 [Suresh]
i will be here until noon session
02:02:15 [bryan_sullivan]
topic: feature permissions
02:02:28 [fjh]
02:02:57 [marengo]
marengo has joined #dap
02:03:21 [Gyubonh]
Gyubonh has joined #dap
02:03:59 [bryan_sullivan]
anssik: the feature permissions spec is being produced by web notiifications group
02:04:00 [AnssiK]
02:04:39 [bryan_sullivan]
anssik: the deliverable is proposed to be moved to DAP
02:04:44 [lgombos]
I reached John Gregg and touch based on the spec
02:05:28 [AnssiK]
02:05:30 [bryan_sullivan]
anssik: I have done some investigation and as demo that implements this with a usable interface
02:05:42 [Gyubong]
Gyubong has joined #dap
02:05:49 [lgombos]
John Gregg has no particular plan to advance the spec for the needs that the WebNotification group has
02:05:51 [Gyubong]
Present+ Gyubong_Oh
02:06:38 [bryan_sullivan]
anssik: the demo should run in any browser; open the link and click the run buttons which will execute the code and show an information bar
02:07:20 [AnssiK]
02:07:37 [bryan_sullivan]
anssik: some changes have been proposed to the DAP spec based upon the investigation
02:09:18 [bryan_sullivan]
anssik: suggest to use this demo to evaluate whether this is a good idea to decouple the permissions from the API invocations; this is just one way to implement the UI, e.g. from usability point of view, e.g. a drag and drop API from the chrome to the page. Constrained devices would need other UI approaches.
02:09:41 [darobin]
+10 on prototypes
02:10:07 [bryan_sullivan]
dom: this is a good way to consider our motivation to do this work
02:10:46 [bryan_sullivan]
dom: this could be useful for other specs outside DAP, e.g. geolocation, some APIs in webapps etc
02:11:20 [dom]
02:11:26 [bryan_sullivan]
dom: if you can bring in the Feature Permissions spec and propose changes based upon the investigation, that would be a start
02:11:56 [lgombos]
dom: I think we should merge the two
02:12:02 [bryan_sullivan]
dom: a question is the relationship to the current API perms draft
02:12:57 [bryan_sullivan]
lgombos: I have looked at this and we should merge the two specs - there are a few APIs with valid scope - we should consider what other APIs would possibly be in scope
02:14:09 [bryan_sullivan]
dom: first we need to get and editor, integrate anssi's comments, and the APIs in scope, and then go to FPWD or contact the other groups to let them know we have this work and a prototype, so see if they are interested. The first step is to take ownership of the spec.
02:14:32 [bryan_sullivan]
logombos: will take on the spec merging task
02:14:48 [fjh]
s/get and editor,/get an editors draft in DAP space/
02:16:02 [Suresh]
Contacts/Calendar? but we may need Rich..
02:16:13 [AnssiK]
I'm happy to help Laszlo with editing Feat Perms
02:17:23 [Liao_Jun]
Liao_Jun has joined #dap
02:17:33 [bryan_sullivan]
topic: success criteria
02:19:37 [Zakim]
02:20:04 [fjh]
suresh expressed concern about chartering limiting to browser context rather than also allowing widgets
02:20:16 [bryan_sullivan]
suresh: we left off where my comment was that the success criteria based upon the default browser model is too restrictive; we should avoid discussions re whether an approach will not work in the browser context but consider it more broadly, e.g. a policy framework can enable the apps to run the same in a browser or widget context
02:21:35 [bryan_sullivan]
fjh: unclear about the reference to framework - our rationales were discussed e.g. avoiding plugins - our result was that this does not preclude widgets as long as plugins were not involved
02:22:16 [bryan_sullivan]
dom: the current charter references the browser context as the main reference point
02:22:18 [Suresh]
thanks DOM
02:22:26 [Suresh]
02:23:18 [bryan_sullivan]
darobin: everything that works in a browser should work in a widget, but the converse is not true
02:23:53 [Zakim]
02:24:18 [bryan_sullivan]
dom: a concrete example is e.g. we discussed message reading as out of scope as its difficult to see how to implement this in a browser context due to security
02:24:20 [Suresh]
replacing the current statement with "APIs that can be demonstrated
02:24:20 [Suresh]
without the need of a specialized policy framework will be released" is a good
02:24:20 [Suresh]
alternative to indicate that the APIs will be demonstrated using the web
02:24:20 [Suresh]
runtime only and not with the assumption of an underlying policy framewrok
02:24:20 [Suresh]
which appeared to be the main concern from browser vendors
02:24:47 [AnssiK]
AnssiK has joined #dap
02:24:58 [bryan_sullivan]
fjh: as rechartering we are increasing scope, and will have trouble delivering
02:24:58 [darobin]
"without the need of a specialised policy framework" doesn't really help — it needs to also be safe
02:25:12 [darobin]
and if it's safe and works without policy — then it works in a browser
02:25:53 [bryan_sullivan]
dom: what we have heard from browser vendors is that they object to working on things that don't work in the open web
02:26:16 [wuj_]
wuj_ has joined #dap
02:26:25 [fjh]
s/increasing scope/increasing number of deliverables/
02:26:31 [fjh]
s/trouble/enough work/
02:26:39 [bryan_sullivan]
suresh: we need to understand the "open web" and what works in different contexts more clearly
02:26:51 [AnssiK1]
AnssiK1 has joined #dap
02:26:55 [fjh]
s/delivering/delivering, might not be wise to add more
02:27:09 [AnssiK]
AnssiK has joined #dap
02:27:11 [fjh]
rrsagent, generate minutes
02:27:11 [RRSAgent]
I have made the request to generate fjh
02:27:15 [bryan_sullivan]
suresh: I would rather that we stay silent or generic on the context
02:27:37 [bryan_sullivan]
darobin: it is generic, we need APIs that are safe in an untrusted environment
02:28:14 [bryan_sullivan]
dom: a main hypothesis is that if it works in the browser it should work in other contexts
02:29:07 [dom]
Suresh, are you trying to make it so that the group scope included non-browsers-compatible APIs, or are you trying to clarify that our APIs will also work beyond the browser context?
02:29:47 [bryan_sullivan]
dom: given the group's current progress, we should not expand the charter scope
02:30:31 [bryan_sullivan]
suresh: do we expect tests to demonstrate ability to use the APIs in both browser and widget contexts?
02:32:18 [bryan_sullivan]
suresh: the discussions that are concerning are those e.g. saving contacts not having a simple way to represent in the browser context, which unecessarily limit the implementation choices
02:33:23 [bryan_sullivan]
dom: the concerns about usability and security are constraints on the process, which needs to verify whether things are really usable and safe
02:33:35 [dom]
s/process/design process/
02:34:30 [bryan_sullivan]
suresh: how do we capture these objectives in the charter, and keep the door open to flexibility in API design?
02:35:01 [bryan_sullivan]
dom: unless we can prove it works in a browser context, we should not work on it
02:36:09 [bryan_sullivan]
dom: there are a number of criteria to consider, the best way to prove something works is to provide a prototype
02:36:29 [bryan_sullivan]
dom: the intent of the charter scope is to limit meta discussions
02:37:27 [bryan_sullivan]
dom: re including widgets in the charter, we have made some efforts to remove it to prevent misconceptions, but new text can be proposed on the list
02:37:56 [bryan_sullivan]
suresh: the issue seemed to be more with the security than widgets
02:38:07 [dom]
s/security/policy framework/
02:38:28 [bryan_sullivan]
suresh: my proposal was to say e.g. if the API is designed to run without a policy framework, it passes the criteria
02:38:50 [bryan_sullivan]
suresh: is that something that can be in the success crieria?
02:39:50 [bryan_sullivan]
bryan: could we rephrase this as "installable web applications" instead of widgets, to be more generic?
02:39:57 [fjh]
02:41:03 [bryan_sullivan]
suresh: does the success criteria affect also the design of the API?
02:42:34 [bryan_sullivan]
dom: the difficulty we have is to convince browser vendors that the DAP APIs are important to them. We would live with the current criteria in the charter and consider the results on an API by API basis e.g. what contexts are supported and how the success criteria is met
02:42:48 [dom]
s/is met/is met during CR/
02:43:09 [Suresh]
"However, this does not preclude the APIs to be demonstrated in Widgets or Installed environments"
02:43:36 [bryan_sullivan]
suresh: we should have a statement re "the intent is not to preclude..."
02:44:12 [darobin]
darobin has joined #dap
02:44:53 [bryan_sullivan]
darobin: the restrictions are focused around ensuring the APIs work in a Web context
02:45:47 [bryan_sullivan]
suresh: will add something to the charter based upon Suresh's proposals, e.g. referencing "not precluding support for installable web applications".
02:47:22 [dom]
02:47:40 [bryan_sullivan]
topic: security
02:47:52 [bryan_sullivan]
darobin: where is content security policy going?
02:48:29 [darobin]
-> Content Security Policy
02:48:34 [bryan_sullivan]
dom: this is a mozilla-led spec intended to limit XSS attack, enabling external website resources to be used safely
02:48:39 [Chen_Bo]
Chen_Bo has joined #dap
02:49:17 [bryan_sullivan]
dom: robin asked where this is going - a charter for "Web Applications Security" was sent to the AC a year ago - it's delayed to find a chair and determine interest
02:49:35 [bryan_sullivan]
dom: this included CORS and UMP
02:52:20 [bryan_sullivan]
darobin: our work may include a "COW" document "Characterization of the Open Web" (what are the properties that define the open web) - as a way to be clear about our scope critera
02:53:09 [bryan_sullivan]
dom: we could throw some ideas on the wiki to see what sticks
02:53:19 [darobin]
ACTION: Robin to get the COW started
02:53:20 [trackbot]
Created ACTION-364 - Get the COW started [on Robin Berjon - due 2011-03-23].
02:53:41 [darobin]
ACTION: Frederick to help raise the COW
02:53:41 [trackbot]
Created ACTION-365 - Help raise the COW [on Frederick Hirsch - due 2011-03-23].
02:54:16 [wuj_]
wuj_ has joined #dap
02:55:00 [bryan_sullivan]
bryan: this would include security approaches, right?
02:55:12 [bryan_sullivan]
darobin: yes, trust and security
02:58:16 [bryan_sullivan]
bryan: this will be important to help us find the way forward on security, what is being provided by other groups, and how what we have drafted already (e.g. feature permissions) fits in an "open web" model as compared to a widget model
02:58:43 [bryan_sullivan]
topic: testing
02:59:03 [dom]
02:59:03 [trackbot]
ACTION-298 -- Dominique Hazaël-Massieux to work with rich on test-enabling the contacts API -- due 2011-03-09 -- OPEN
02:59:03 [trackbot]
02:59:03 [bryan_sullivan]
darobin: we need to test contacts soon
02:59:10 [fjh]
close ACTION-348
02:59:11 [trackbot]
ACTION-348 Send concrete proposal for navigator.sendMessage with URI scheme closed
02:59:53 [bryan_sullivan]
bryan: what basis for framework and examples wll be used to start?
03:00:37 [bryan_sullivan]
dom: we earlier agreed to use the Webapps javascript framework as used in the HTML tests, XHR, etc
03:00:52 [fjh]
DAP wiki for testing , including framework ->
03:01:28 [bryan_sullivan]
dom: one struggle will be defining a test environment e.g. due to dependency upon underlying data, which may require loading of fake data
03:02:19 [fjh]
Dom is planning on testing related to contacts, so is Rich, plan to make call for contributions later
03:04:44 [AnssiK]
I presented the QUnit-based approach to unit testing at the last f2f
03:05:30 [AnssiK]
03:05:41 [bryan_sullivan]
fjh: what about HTML media capture?
03:05:46 [AnssiK]
the group decided to align with the WebApps WG harness instead
03:05:51 [bryan_sullivan]
dom: we are stuck
03:05:59 [bryan_sullivan]
topic: HTML media capture
03:06:06 [AnssiK]
so I have not made further progress on the unit testing front after that
03:07:00 [bryan_sullivan]
darobin: the "role" attribute is intended for assistive technologies and not for other purposes - we need to find another approach
03:07:00 [AnssiK]
I believe jgraham of Opera is the original author of the WebApps harness contributed to W3C
03:07:16 [AnssiK]
but I'm not 100% sure, Opera participants probably know the best
03:07:31 [dom]
ACTION: Dom to restart with HTML WG on getting new attribute for HTML Media Capture
03:07:31 [trackbot]
Created ACTION-366 - Restart with HTML WG on getting new attribute for HTML Media Capture [on Dominique Hazaël-Massieux - due 2011-03-23].
03:07:58 [bryan_sullivan]
fjh: we need to update the draft and can then go to last call
03:08:20 [bryan_sullivan]
darobin: better to put out a new WD first
03:09:00 [bryan_sullivan]
darobin: a draft will help get feedback from the HTML WG
03:09:01 [dom]
ACTION: Dom to update HTML Media Capture with new attribute
03:09:01 [trackbot]
Created ACTION-367 - Update HTML Media Capture with new attribute [on Dominique Hazaël-Massieux - due 2011-03-23].
03:09:15 [dom]
ACTION-366: todo after ACTION-367
03:09:15 [trackbot]
ACTION-366 Restart with HTML WG on getting new attribute for HTML Media Capture notes added
03:09:30 [fjh]
plan is to update HTML Media capture, then publish new WD, get feedback, then consider last call
03:10:25 [dom]
03:10:32 [bryan_sullivan]
bryan: what are the steps in getting ready for tests?
03:10:44 [bryan_sullivan]
darobin: there is a methodology
03:11:11 [Gyubong_]
Gyubong_ has joined #dap
03:11:13 [dom]
linked from
03:11:25 [Gyubong_]
Present+ Gyubong_Oh
03:11:56 [bryan_sullivan]
dom: the best way is to identify test assertions and tests to cover them
03:12:24 [bryan_sullivan]
fjh: the spec editors need to use the document markup conventions supporting the test assertions
03:13:16 [bryan_sullivan]
dom: it's more important to just get started on the test assertions
03:13:51 [dom]
s/the test assertions/creating tests, and then progress through an interative process/
03:14:31 [bryan_sullivan]
fjh: the test assertions and tests are essential to move spec further in the process...
03:18:07 [dom]
-> Web Tracking and User Privacy Workshop, April 28-29
03:19:35 [dom]
[we're breaking until 2pm local time]
03:27:36 [Zakim]
03:29:55 [Zakim]
03:50:31 [homata]
homata has joined #dap
03:55:28 [Zakim]
03:59:51 [AnssiK]
AnssiK has joined #dap
04:06:32 [AnssiK]
AnssiK has joined #dap
04:31:31 [marengo]
marengo has joined #dap
04:31:38 [minkyo]
minkyo has joined #dap
04:35:00 [darobin]
darobin has joined #dap
04:51:11 [Zakim]
04:51:13 [Zakim]
UW_DAP(DAPWGF2F)7:00PM has ended
04:51:15 [Zakim]
Attendees were DAPWG, Suresh, AnssiK, +1.781.534.aaaa, laszlo
04:55:41 [fjh]
fjh has joined #dap
04:59:08 [ktaklee]
ktaklee has joined #dap
04:59:16 [ktaklee]
Present+ Kyung-Tak_Lee
05:05:42 [dom]
Zakim, room for 4?
05:05:43 [Zakim]
ok, dom; conference Team_(dap)05:05Z scheduled with code 26631 (CONF1) for 60 minutes until 0605Z
05:05:59 [Zakim]
Team_(dap)05:05Z has now started
05:06:06 [Zakim]
05:06:21 [dom]
AnssiK, we'll be using 26631 as a conf code; I'm not sure why the regular one doesn't work
05:06:25 [dom]
Zakim, ??P0 is DAPWG
05:06:25 [Zakim]
+DAPWG; got it
05:07:05 [dom]
ScribeNick: dom
05:07:40 [Zakim]
05:07:47 [AnssiK]
zakim, ??P1 is me
05:07:47 [Zakim]
+AnssiK; got it
05:08:40 [dom]
Topic: Contacts API
05:08:55 [dom]
-> Contacts API Editors draft
05:09:51 [dom]
Frederick: actually, let's start with Gallery
05:09:54 [dom]
Topic: Gallery API
05:10:09 [dom]
05:10:09 [trackbot]
ACTION-314 -- Anssi Kostiainen to react on media gallery use cases -- due 2010-12-15 -- OPEN
05:10:09 [trackbot]
05:11:01 [wonsuk]
wonsuk has joined #dap
05:11:39 [fjh]
05:11:45 [dom]
Anssi: should look at use cases before deciding to work on it
05:11:57 [dom]
... also need to check how much priority this should get
05:12:04 [darobin]
05:12:15 [dom]
... we got some useful list of use cases from francois
05:12:32 [Chen_Bo]
Chen_Bo has joined #dap
05:12:34 [dom]
... could look at prototyping
05:13:13 [Gyubong]
Gyubong has joined #dap
05:13:21 [BJ]
BJ has joined #dap
05:13:22 [dom]
Anssi: there has been little progress under the current charter
05:13:34 [BJ]
Present+ BJ_Kim
05:13:39 [dom]
... at the last F2F we quickly hacked together some quick design to replice the BONDI replica
05:13:41 [Gyubong]
Present+ Gyubong_Oh
05:13:53 [dom]
... I'm trying to find out if that's on the critical path
05:14:21 [dom]
...does the the group feel that the deliverable has decent use cases and there is demand from developers
05:14:39 [Liang_Yan]
Liang_Yan has joined #dap
05:14:41 [dom]
... before investing time in a new draft
05:16:03 [Chen_Bo]
Chen_Bo has joined #dap
05:16:29 [dom]
... coming up with good design and prototype will require some of my time that would be taken away from other deliverables work
05:16:39 [dom]
... it's still largely unproven
05:18:35 [Zakim]
05:19:47 [fjh]
fjh has joined #dap
05:19:58 [Zakim]
05:21:05 [Kangchan]
Kangchan has joined #dap
05:21:44 [Zakim]
05:22:18 [fjh]
fjh has joined #dap
05:22:32 [Zakim]
05:22:49 [darobin]
we're still switching to someone else
05:23:01 [Zakim]
05:23:40 [Zakim]
05:23:51 [Zakim]
+ +358.504.86aaaa
05:23:52 [darobin]
05:24:09 [AnssiK]
zakim, aaaa is me
05:24:09 [Zakim]
+AnssiK; got it
05:24:42 [wonsuk]
wonsuk has joined #dap
05:25:03 [minkyo]
minkyo has joined #dap
05:25:17 [darobin]
AnssiK: what is the kind of consensus around the priority for that API?
05:25:20 [dom_]
dom_ has joined #dap
05:25:25 [darobin]
... I don't think that it has a proven track record
05:25:30 [fjh]
q+ to ask about how much to to be done
05:25:34 [darobin]
... not sure if the BONDI version materialised at all
05:25:50 [Zakim]
05:27:22 [dom_]
ScribeNick: dom_
05:27:37 [wuj_]
wuj_ has joined #dap
05:27:39 [Dong-Young]
Dong-Young has joined #dap
05:27:43 [marengo_]
marengo_ has joined #dap
05:27:50 [darobin]
darobin has joined #dap
05:27:58 [Kangchan]
Kangchan has joined #dap
05:28:03 [darobin]
05:28:04 [fjh]
zakim, who is here?
05:28:04 [fjh]
zakim, who is here?
05:28:04 [fjh]
zakim, who is here?
05:28:04 [Zakim]
On the phone I see ??P0, AnssiK
05:28:05 [Zakim]
On the phone I see ??P0, AnssiK
05:28:07 [Zakim]
On the phone I see ??P0, AnssiK
05:28:09 [Zakim]
On IRC I see Kangchan, darobin, marengo_, Dong-Young, wuj_, dom_, minkyo, fjh, Chen_Bo, BJ, Gyubong, ktaklee, marengo, AnssiK, homata, sungok, donghyun_kang, Zakim, RRSAgent,
05:28:14 [Zakim]
... soonho, richt, ilkka, lgombos, ingmar, dom, trackbot
05:28:19 [darobin]
we're redialing
05:28:21 [wonsuk]
wonsuk has joined #dap
05:28:25 [Zakim]
05:28:31 [Liang_Yan]
Liang_Yan has joined #dap
05:28:32 [Dong-Young]
Present+ Dong-Young_Lee
05:28:33 [shan]
shan has joined #dap
05:28:35 [Zakim]
05:28:36 [Zakim]
05:28:46 [dom_]
Zakim, [IPcaller] is DAPWG
05:28:46 [Zakim]
+DAPWG; got it
05:28:50 [fjh]
fjh has joined #dap
05:29:06 [dom_]
05:29:07 [darobin]
... not clear that there's much prior art in this
05:29:10 [dom_]
ack fjh
05:29:10 [Zakim]
fjh, you wanted to ask about how much to to be done
05:29:20 [dom_]
Frederick: how much work do you think this requires?
05:29:24 [minkyo]
minkyo has joined #dap
05:30:13 [dom_]
Anssi: the requirements from the use cases would require quite a number of features
05:30:20 [dom_]
... would probably start with something small
05:30:31 [dom_]
... I'm struggling to find what would be low-hanging fruit
05:30:36 [dom_]
... I welcome ideas around that
05:31:26 [dom_]
... we could simply conclude that we don't have currently enough interest
05:31:38 [dom_]
... whereas if it's clear that we have RoI, then I'm happy to do that
05:31:42 [dom_]
05:31:51 [fjh]
ack dom_
05:31:52 [dom_]
... I could do a small thing as a trigger for discussions
05:32:00 [fjh]
+1 to low cost evaluation of where to begin
05:32:37 [dom_]
... we could probably take a file-picker approach for low-hanging — but not clear this brings any additional value over existing APIs
05:32:55 [darobin]
+1 to code and small things
05:33:42 [dom_]
Dom: I would suggest doing some very rough, maybe a number of code examples of what the API would like
05:34:00 [dom_]
... and then bring it to the Web & TV IG to get feedback on usefulness/importance
05:34:43 [Liao_Jun]
Liao_Jun has joined #dap
05:34:55 [Liao_Jun]
Present+ Jun_Liao
05:35:54 [dom_]
... for instance, being able to search through your recorded collection of movies on your TV set-top box from your smartphone
05:36:10 [wonsuk]
web and TV paper related with gallery API:
05:36:14 [dom_]
... could also look at position paper I noted to the mailing list which mentioned the need for a gallery API
05:36:36 [fjh]
rrsagent, generate minutes
05:36:36 [RRSAgent]
I have made the request to generate fjh
05:36:47 [dom_]
Wonsuk: we need to make clear use cases for Gallery API
05:36:54 [dom_]
... we got use cases from Dom and Francois
05:37:02 [dom_]
... we also got one from Web & TV workshop
05:37:22 [dom_]
... we should enhance the use cases in the Gallery API doc
05:37:39 [dom_]
... might need also input to file systems API
05:38:13 [dom_]
ACTION: Wonsuk to collect and summarize current use cases for Gallery API and includes a draft doc
05:38:13 [trackbot]
Created ACTION-368 - Collect and summarize current use cases for Gallery API and includes a draft doc [on WonSuk Lee - due 2011-03-23].
05:38:48 [dom_]
Wonsuk: there are lots of related specs: HTML Media Capture, Media Annotations, Media Ontology, FileSystems API
05:39:02 [dom_]
... this will require significant coordination
05:39:57 [dom_]
Dom: think writing code samples is best way to approach that complexity
05:40:03 [dom_]
s/best/the best/
05:40:15 [dom_]
Topic: Contacts API
05:41:11 [dom_]
-> Discussion during last teleconf on Contacts API
05:42:16 [dom_]
Dom: only remaining thing is removing search filters, and then we can make a call for consensus for Last Call
05:43:11 [dom_]
Frederick: ok, so not much to discuss then
05:43:23 [dom_]
Topic: Calendar API
05:43:45 [fjh]
05:43:54 [darobin]
05:44:01 [AnssiK]
05:44:04 [dom_]
Robin: could we go move forward with FPWD for Calendar?
05:44:07 [AnssiK]
05:44:15 [dom_]
Dom: we have a dependency on TZDate
05:44:34 [dom_]
Robin: doesn't seem to be a blocker for FPWD
05:44:40 [dom_]
Anssi: (back to Contacts)
05:44:46 [dom_]
... there has been an update to vCard 4
05:45:03 [dom_]
... don't think the last changes have an effect on Contacts, but could check
05:45:20 [dom_]
Robin: I think Richard looked
05:45:27 [dom_]
... vCard4 is a superset of vCard3
05:45:43 [fjh]
q+ to ask about publishing updated WD of calendar
05:45:58 [dom_]
Anssi: vCard2 and 3 were not explicit about the timezone format
05:45:59 [fjh]
ack AnssiK
05:46:17 [dom_]
i/Anssi: (/Topic: Contacts Again
05:46:29 [dom_]
... I sent a message to the list with a report on the differences
05:46:47 [fjh]
rrsagent, generate minutes
05:46:47 [RRSAgent]
I have made the request to generate fjh
05:47:17 [AnssiK]
05:47:49 [fjh]
s/ (back to Contacts)/Topic: Contacts (again)/
05:47:55 [fjh]
rrsagent, generate minutes
05:47:55 [RRSAgent]
I have made the request to generate fjh
05:48:24 [dom_]
... Olsson database is the recommended way, but many implementations only use utcOffset
05:48:31 [dom_]
Dom: This matches what's currently in the API
05:48:47 [fjh]
Topic: Calendar (again)
05:49:03 [dom_]
Robin: would be good to go to FPWD
05:49:20 [dom_]
Frederick: +1
05:49:41 [dom_]
Robin: would need maybe a quick review to remove most important bugs
05:50:03 [fjh]
ack fjh
05:50:03 [Zakim]
fjh, you wanted to ask about publishing updated WD of calendar
05:50:26 [dom_]
Dom: should do a call for consensus
05:50:41 [fjh]
05:50:46 [dom_]
Dom: would like to make sure that the issue re TZDate is clearly documented in the draft, to avoid worrying people
05:51:05 [dom_]
... likewise for the recurrence model limitations
05:53:20 [dom_]
Robin: will send CfC then
05:53:23 [dom_]
Dom: I'll add the note on the issues in the draft
05:53:32 [BJ]
BJ has joined #dap
05:53:38 [Gyubong]
Gyubong has joined #dap
05:53:41 [sungok]
sungok has joined #dap
05:53:47 [BJ]
Present+ BJ_Kim
05:53:47 [Gyubong]
Present+ Gyubong_Oh
05:53:50 [shan]
shan has joined #dap
05:53:53 [Kangchan]
Kangchan has joined #dap
05:54:02 [donghyun_kang]
donghyun_kang has joined #DAP
05:55:18 [wuj_]
wuj_ has joined #dap
05:59:35 [Kangchan]
Kangchan has joined #dap
06:00:11 [sungok]
sungok has joined #dap
06:08:27 [soonho]
soonho has joined #dap
06:08:38 [dom]
ScribeNick: dom
06:10:15 [shan]
shan has joined #dap
06:10:23 [BJ]
BJ has joined #dap
06:12:01 [wonsuk]
wonsuk has joined #dap
06:14:34 [fjh]
Topic: Roadmap
06:14:43 [fjh]
06:14:55 [dom]
-> DAP Roadmap
06:17:13 [Dong-Young]
Dong-Young has joined #dap
06:17:56 [dom]
Frederick: we will not be meeting on Friday since we have already gone through the agenda and people have started to depart early
06:18:07 [minkyo]
minkyo has joined #dap
06:18:31 [dom]
Frederick: regarding our roadmap, the rechartering doesn't prevent us from continuing our existing work, right?
06:18:37 [dom]
dom: right
06:18:41 [Chen_Bo]
Chen_Bo has joined #dap
06:18:51 [dom]
Frederick: let's look at our roadmap then
06:19:22 [dom]
... we've determined a path for contacts
06:19:34 [dom]
... likewise for Calendar, we've just sent a CfC for FPWD
06:20:08 [dom]
Robin: if contacts goes to last call, we can hope to go to LC with Calendar soon (maybe June?)
06:20:15 [dom]
Zakim, who's on the phone?
06:20:15 [Zakim]
On the phone I see ??P0, DAPWG, AnssiK
06:20:35 [dom]
Frederick: what about HTML Media Capture?
06:20:48 [dom]
Robin: we're planning to publish an updated draft with a new attribute
06:20:51 [Kyungtak]
Kyungtak has joined #dap
06:21:05 [AnssiK]
06:21:07 [dom]
... and depending on feedback, we might be able to go to LC soon
06:22:05 [AnssiK]
Any feedback from Google? "As defined by the HTML Media Capture specification, the Browser allows web applications to access audio, image and video capture capabilities of the device."
06:22:50 [fjh]
contacts - we have remaining edit from Rich, then CfC to go to Last Call in April
06:23:14 [fjh]
calendar - CfC in place for publishing FPWD
06:23:18 [fjh]
in April
06:23:30 [dom]
PROPOSED RESOLUTION: we will publish a new updated HTML Media Capture once new attribute is done
06:23:39 [fjh]
HTML Media Capture, outstanding edit from Dom then publish updated WD
06:23:46 [dom]
Robin: you'll need to add an API for the new attribute based on WebIDL
06:23:58 [dom]
... might use white-space separated tokens
06:24:03 [dom]
RESOLUTION: we will publish a new updated HTML Media Capture once new attribute is done
06:24:29 [fjh]
Media Capture API - looking for feedback on interest in it
06:24:53 [dom]
close ACTION-351
06:24:53 [trackbot]
ACTION-351 Draft HTML Media Capture with role attribute closed
06:24:59 [AnssiK]
-> Microsoft's feedback
06:25:23 [Gyubong]
Gyubong has joined #dap
06:25:30 [dom]
ACTION: Robin to talk with Microsoft re Capture API future
06:25:30 [trackbot]
Created ACTION-369 - Talk with Microsoft re Capture API future [on Robin Berjon - due 2011-03-23].
06:25:36 [Gyubong]
Present+ Gyubong_Oh
06:26:30 [soonho]
Present+ Soonho_Lee
06:26:31 [dom]
Frederick: I think we're wondering about keeping it at all, vs upgrading it with stream support
06:28:31 [dom]
Robin: I would qualify it as "future under discussion", decision expected sometimes in April
06:29:48 [dom]
Frederick: Messaging will be updated with the new approach
06:30:07 [dom]
Dom: and if no negative feedback, we can hope to go to last call in June
06:30:37 [dom]
Dom: re sysinfo, lots of work to take into account the new split
06:31:20 [dom]
... I guess the plans for last call are probably less clear
06:31:35 [dom]
Robin: some might be relatively straightforward
06:31:44 [dom]
Dom: indeed, maybe Network could go quickly to LC
06:32:49 [fjh]
Messaging - also updated WD in April
06:33:45 [dom]
Frederick: Permissions API will get a FPWD
06:34:07 [dom]
Dom: open question on merging the permissions API with the permissions strings
06:34:17 [dom]
Robin: I'd rather keep them separate but don't mind strongly
06:35:24 [dom]
Anssi: we could probably go fast unless we need coordination with Web Notif
06:35:32 [dom]
Dom: don't think we need to coordinate
06:35:42 [dom]
Frederick: so we can plan for a FPWD in April
06:35:57 [fjh]
s/FPWD/FPWD of Permissions/
06:36:11 [dom]
Anssi: first step will be to put draft into ReSpec format
06:36:15 [dom]
... and then bring in my changes
06:36:30 [dom]
... I can do start and then pass it to Lazlo for review
06:37:31 [BJ]
BJ has joined #dap
06:38:00 [AnssiK]
06:38:11 [dom]
Frederick: [bashing ReSpec]
06:38:20 [fjh]
s/bashing/expressing admiration for/
06:38:35 [dom]
Anssi: regarding merging with features ids or not
06:38:46 [dom]
... I think they're independent
06:38:57 [fjh]
we should ReSpec for our drafts to pick up common formatting, bibliography etc
06:39:52 [dom]
Dom: thinking about it, I think they need to be kept independent since features ids are also useful for widgets feature
06:40:20 [dom]
... we should publish an updated draft referring to the API once we go with FPWD
06:40:59 [dom]
Anssi: wondering where the feature strings should go
06:41:09 [dom]
... ideally, I think they should come with the API spec themselves
06:41:14 [dom]
... but that's probably a minor issue
06:42:41 [dom]
... I'm thinking the feature string could be a serialization of the entry of the APIs e.g. navigator.geolocation
06:42:56 [dom]
Dom: I don't think that would work for all cases, e;g. when no direct entry point but from DOM element
06:43:07 [dom]
... so I think arbitraty strings are probably our best option
06:43:19 [dom]
Anssi: true
06:43:46 [dom]
Frederick: for Gallery?
06:43:56 [dom]
Dom: plan is to come up with code samples, formalized use cases
06:44:01 [dom]
Robin: not ready to publish as is
06:44:51 [dom]
Dom: re Device Interface?
06:44:52 [fjh]
will wait with Gallery until clarity on requirements and draft
06:45:12 [dom]
Robin: can have a draft next month
06:45:19 [dom]
Dom: but do we still actually need it?
06:45:29 [dom]
Robin: Contacts API doesn't use it anymore
06:45:45 [dom]
Dom: now that we mention it, Contacts doesn't do HTML5 Event loop correctly, does?
06:45:55 [dom]
Robin: doesn't look like it
06:46:20 [dom]
06:46:20 [trackbot]
ACTION-271 -- Robin Berjon to figure out the event loop stuff for sysinfo -- due 2010-09-22 -- OPEN
06:46:20 [trackbot]
06:47:25 [dom]
ISSUE: Contacts API needs to integrate HTML Event Loop
06:47:25 [trackbot]
Created ISSUE-110 - Contacts API needs to integrate HTML Event Loop ; please complete additional details at .
06:48:07 [dom]
Dom: so that's a showstopper for moving to LC
06:48:21 [dom]
Robin: I hope the work in Web Apps for this for file API can serve as inspiration
06:49:08 [dom]
... I'm not entirely sure if that's entirely needed
06:49:39 [dom]
ACTION-271 due 2011-03-23
06:49:39 [trackbot]
ACTION-271 Figure out the event loop stuff for contacts due date now 2011-03-23
06:50:07 [dom]
Dom: moving back to Device Interface, should we drop it then?
06:50:25 [fjh]
Not going further with Device interface
06:50:29 [dom]
Robin: if nobody using it, sure
06:50:56 [fjh]
Application Launcher,
06:51:34 [dom]
Dom: re Application Launcher, we've talked about using Web Intents
06:51:46 [dom]
... but we don't have a plan for it
06:52:03 [dom]
Robin: I don't think anybody has volunteered for that
06:52:43 [dom]
Dom: we could make a call for editors
06:52:50 [darobin]
ACTION: Robin to talk to Mozilla/Paul about Web Intents
06:52:50 [trackbot]
Created ACTION-370 - Talk to Mozilla/Paul about Web Intents [on Robin Berjon - due 2011-03-23].
06:53:29 [dom]
Kangchan: the proposed approach of Web Intent is quite different from the current API
06:53:44 [dom]
... I've started discussing with Bryan and Paul to reconcile the views on this
06:55:22 [dom]
Dom: what about Web Introducer? Should it be added to the roadmap
06:55:41 [dom]
... ?
06:55:43 [darobin]
ACTION: Robin to talk to Claes about how to make Web Introducer happen in the WG
06:55:43 [trackbot]
Created ACTION-371 - Talk to Claes about how to make Web Introducer happen in the WG [on Robin Berjon - due 2011-03-23].
06:55:48 [dom]
Robin: I think that would make sense
06:56:01 [dom]
... we need to see if they're still interested in doing work on this as part of the group
06:56:22 [dom]
06:56:22 [trackbot]
ACTION-353 -- Dominique Hazaël-Massieux to check with Claes re Web introducer contributors and bringing it to DAP -- due 2011-03-22 -- OPEN
06:56:22 [trackbot]
06:56:24 [fjh]
it would be best to have active participation of those who created the draft in the DAP WG
06:56:34 [dom]
close ACTION-353
06:56:34 [trackbot]
ACTION-353 Check with Claes re Web introducer contributors and bringing it to DAP closed
06:56:46 [dom]
ACTION-353: overtaken by ACTION-371
06:56:46 [trackbot]
ACTION-353 Check with Claes re Web introducer contributors and bringing it to DAP notes added
06:57:13 [dom]
Dom: next is Tasks
06:57:38 [dom]
... it has been suggested it could be a simple addition to the Calendar API
06:58:25 [dom]
Frederick: would qualify as unscheduled work for now
06:59:36 [dom]
Dom: will add relationship to Calendar in roadmap too
07:00:01 [dom]
... probably worth taking up with the Calendar editors to see if they want to fold it in
07:00:15 [fjh]
might make sense to include tasks with calendar since tasks are time based events
07:02:02 [dom]
How does tasks relate to Process management?
07:02:14 [dom]
Dom: different topic, but we could consider process management as part of new charter
07:02:35 [dom]
Robin: please send use cases and potential input to the list if you want to include it in consideration for new charter
07:03:16 [dom]
Dom: nothing has been done on User Interaction
07:03:33 [dom]
... we want to do vibration, beep and menus per our new charter
07:03:52 [dom]
... Opera has said they have proposals in this space
07:03:59 [dom]
Robin: for menus and vibration
07:04:17 [dom]
ACTION: Dom to talk with Opera on contributions for User Interactions deliverable
07:04:17 [trackbot]
Created ACTION-372 - Talk with Opera on contributions for User Interactions deliverable [on Dominique Hazaël-Massieux - due 2011-03-23].
07:04:40 [dom]
Dom: Communication Log to be dropped
07:04:53 [dom]
... likewise for Policy Framework
07:05:03 [dom]
Frederick: we should keep ref to them in a history section somewhere
07:05:36 [dom]
Dom: re APIs requirements, can hope to update for May
07:05:51 [dom]
ACTION-281 due 2011-05-10
07:05:51 [trackbot]
ACTION-281 Take a stab at updating the API Requirements documents due date now 2011-05-10
07:06:29 [dom]
Dom: policy-reqs is probably done
07:06:46 [dom]
Robin: should we end of life it?
07:07:03 [dom]
Frederick: we might want to update it at some point
07:07:38 [dom]
Dom: we could publish it as a note to mark it as done
07:08:19 [dom]
ACTION: Frederick to prepare policy-reqs as WG Note
07:08:19 [trackbot]
Created ACTION-373 - Prepare policy-reqs as WG Note [on Frederick Hirsch - due 2011-03-23].
07:09:07 [dom]
Dom: what about privacy-reqs?
07:09:18 [dom]
Frederick: it's an important doc
07:11:29 [dom]
Dom: how are we intending to make progress on privacy-reqs
07:11:32 [dom]
... ?
07:11:52 [dom]
Frederick: workshops are a way to get input
07:16:18 [dom]
Dom: I think we are less likely to make progress if we don't have a plan, but don't mind keeping it as is
07:16:29 [dom]
Frederick: re Rulesets
07:16:39 [dom]
... I think we should publish it as FPWD, despite its issues
07:16:48 [dom]
Robin: reading the document, it's not clear what it is supposed to do
07:17:30 [dom]
Dom: it doesn't tell how the rulesets are bound to data
07:18:46 [fjh]
so your concern is the lack of clarify of how this would integrate in the API architecture
07:19:01 [dom]
Robin: I still think there is no point in using Rulesets in the same way as Geopriv
07:19:30 [dom]
... attaching information to an API is something that no-one wants to do
07:20:49 [dom]
Dom: we had interesting discussions in a previous F2F about using rulesets only in some cases (e.g. with Web site with which you have no pre-exisitng relationship)
07:20:56 [dom]
... there were quite a few ideas
07:21:06 [fjh]
possible need to capture ideas in rulesets proposal for this and other ideas
07:21:10 [dom]
... but they need to be captured as text and discussed if we want to make progress
07:21:43 [dom]
ACTION: Frederick to complete Privacy Rulesets with binding considerations
07:21:43 [trackbot]
Created ACTION-374 - Complete Privacy Rulesets with binding considerations [on Frederick Hirsch - due 2011-03-23].
07:22:19 [dom]
Dom: last one is API Design Patterns, can be removed
07:22:41 [dom]
ACTION: Dom to add API Checklist to home page
07:22:41 [trackbot]
Created ACTION-375 - Add API Checklist to home page [on Dominique Hazaël-Massieux - due 2011-03-23].
07:23:44 [dom]
Dom: I think documenting our experience could be useful
07:23:54 [dom]
... could help make the Web a better place
07:24:14 [dom]
... I wouldnt' phrase it as "you should do this or that", but rather here what've faced and learned
07:24:54 [dom]
RRSAgent, draft minutes
07:24:54 [RRSAgent]
I have made the request to generate dom
07:25:56 [BJ]
Present+ BJ_Kim
07:27:01 [fjh]
Thank you to our hosts and Kangchan
07:28:04 [Zakim]
07:29:06 [Zakim]
07:30:35 [fjh]
Next F2F is in July in France, please complete questionnaire
07:31:12 [fjh]
for information on upcoming meetings and minutes see
07:31:17 [wonsuk]
wonsuk has left #dap
07:31:27 [fjh]
Topic: Adjourn
07:31:32 [fjh]
rrsagent, generate minutes
07:31:32 [RRSAgent]
I have made the request to generate fjh
07:32:39 [fjh]
Present- DAPWG
07:33:15 [fjh]
rrsagent, generate minutes
07:33:15 [RRSAgent]
I have made the request to generate fjh
07:34:07 [Zakim]
disconnecting the lone participant, ??P0, in Team_(dap)05:05Z
07:34:08 [Zakim]
Team_(dap)05:05Z has ended
07:34:12 [Zakim]
Attendees were DAPWG, AnssiK, +358.504.86aaaa
07:38:09 [BJ]
BJ has left #dap
07:40:01 [JonathanJ]
JonathanJ has joined #DAP
08:35:23 [minkyo]
minkyo has left #dap
08:48:27 [Zakim]
Zakim has left #dap