Draft minutes: 1 November 2011 f2f meeting

• From: Arthur Barstow <art.barstow@nokia.com>
• Date: Wed, 02 Nov 2011 14:09:54 -0700
• To: public-webapps <public-webapps@w3.org>
• Message-ID: <4EB1B1A2.2010201@nokia.com>

The DRAFT minutes from the November 1 f2f meeting are in the following 
document and copied below:



I believe Chaals may do some tidying.

If there are any important (i.e. non-editorial) additions, corrections, 
etc., that need to be made, please respond to this e-mail.

-AB

W3C
- DRAFT -
WebApps f2f meeting
01 Nov 2011

Agenda

See also: IRC log
Attendees

Present
tpac, Olli_Pettay, Ms2ger, Soonho_Lee, magnus, krisk, spoussa, Jacob, 
Israel, SungOk_You, Bryan_Sullivan, Wonsuk_Lee, David_Yushin_Kim, 
Kihong_Kwon, Jesus_Martin, hao_wang, Jonathan_Jeon, Josh_Soref, Robin, 
Cameron, JamesG, Dom, Jonas, Doug, Chaals, Kris, BrianR, Magnus, ArtB, 
MikeSmith, EricU, LaszloG, Sakkari, WayneCarr, Dowan, adrianba, eliot
Regrets
Chair
Chaals, Art
Scribe
Marcosc, Chaals, ArtB, Josh_Soref

Contents

Topics
Agenda (bashing)
Stream and file API
stream API
Testing
API design
D3E and DOM4 Redux
XBL2 and Component Model
IndexDB
Mutations
Server Sent Events: Push
WebIDL
Summary of Action Items

Agenda (bashing)

<Marcos> we look at stream and file API

<Marcos> Need to look at what we do with DOM 3 API at 10am

<Marcos> People who are important are Jakob and Doug, but there is time 
conflict

<Marcos> So we will do it at 11:30 (DOM3 Events)

<Marcos> Testing we also need to discuss

<Marcos> We need Jonas for the File API

<Marcos> Afternoon: index DB and XBL2 and component model, in the afternoon

<Marcos> 1-3pm

<Marcos> Bryan wanted to add an item: Event source extension for 
connectionless push

<Marcos> If we get through stuff quickly, we can start talking about API 
design

<Marcos> Stream and file API, we can start off with that
Stream and file API

<Marcos> Scribe: Marcosc

<Marcos> EU: I want to discuss file saver

<Marcos> Not all the use cases are covered by download attribute on the 
a element.

<Marcos> ee: we had talked about looking at saving a blob VS saving a 
URL (the resource)

<Marcos> ee: is there interest in implementing this?

<Marcos> JS: yes

<Marcos> CMN: nods in agreement

<Marcos> AB: We wanted to replicate the same expirience you get form 
downloading a link. We have implemented two APIs that get sent a blob 
and the browser displays a dialog and simulates downloading a file (but 
using a blob). The idea is to make the user experience is the same.

<Marcos> JS: how is that different from file saver

<Marcos> AB: you don't get the progress events.

<Marcos> AB: going to paste in a URL

<adrianba> http://pages.adrianba.net/w3c/FilesAndStreams.pdf

<Marcos> If you look at the second page… replicating content 
disposition: which shows the save dialog

<Marcos> CMN: is there any indicator when the download is done.

<Marcos> AB: no. it works like the current save dialog that browsers use

<Marcos> CMN: We have the File API right now. And I think that is what 
we want before a full filesystem API. Our use cases are "real file 
system access": create directories, get at files, so the user can share 
files with Apps.

<Marcos> AB: we are not opposed to such an API. But they are not a high 
priority for us (MS) right now.

<chaals> [berjob waltzes in already...]

<Marcos> AB: this is something we did instead of file saver… the file 
system API is further down the road.

<Marcos> EU: how is this different from the current API?

<Marcos> AB: we don't support the download attribute. We don't to 
support navigation to a blob URL. So if the blog points to a URL page, 
we don't want to display that page. we are concerned about scripts 
running in the page contained by the page.

<Marcos> RB: could you not always download it? just a suggestion?

<Marcos> AB: maybe :)

<Marcos> EU: not sure what Chrome does right now. We might be displaying 
it in an iframe. But we are not sure about the origin right now and what 
privileges it has

<Marcos> AB: for use, we have abstract protocol handler…

<chaals> s/EU:/EU:/

<Marcos> EU: It sounds like we have 3 different things that overlap.

<Marcos> JS: I'm very interested in supporting the use cases, but 3 
different ways is not good. I would like to find a way to avoid having 3 
different APIs

<Marcos> JS: file saver could do everything you want

<Marcos> EU: it doesnt have a clean way to allow the user to open the file

<Marcos> JS: but it is fully API driven

<Marcos> JS: it would be nice to find a single way. So it would be nice 
to figure out what the requirements are consolidate them

<Marcos> AB: agree… we don't want to implement multiple API

<Marcos> CMN: its clear that we all want to support the use case…. and 
we don't want to tell devs how to use multiple APIs

<Marcos> [agreement]

<Marcos> AB: Can we talk about file API first

<Marcos> before moving on to stream

<Marcos> In the first page of the first page: readAsBinaryString… is 
there a strong use case for it? is that for legacy reasons?

<Marcos> JS: It is. But it's ok to drop it

<Marcos> AB: We would like to see it removed

<Marcos> JS: it's more legacy, so I'm ok with dropping it

<Marcos> MC: Second question: do we really need the restrictions on the URL?

<Marcos> JS: I have not looked at the URL part

<Marcos> Arun has been working on it. But he would probably be 
interested in discussing it further

<Marcos> AB: the third thing is a suggestion: a really common pattern is 
to have an URL that represents something (e.g., an image). So one of the 
things that we have implemented is boolean flag, that creates a one time 
URL. The first time it gets dereferenced, it loads and it goes away

<Marcos> AB: final question, I'm wondering if it's ever possible to see 
the protocol version that is dereferenced in from the blob URL

<Marcos> ?

<Marcos> AB: we proposed it's not necessary

<Marcos> JS: agree, but Arun should have a look

<Marcos> JS: another proposal is to drop BlobBuilder in favour of a 
contructor

<adrianba> http://html5labs.com/streamsapi/
stream API

<Marcos> when we started working on the blob API, a req was to have a 
blob whose size was unknown (a steam).

<Marcos> AB: feedback we got was don't make it blob, make it something 
else… so it's how we ended up with at stream… so we have a Stream 
Reader, which allows you to covert to a blob. We make the stream 
available at ready state 3, instead of 4. It allows people to view media 
before the whole thing finishes

<Marcos> E.g. in a mail app, you can start viewing stuff at readystate 
3, and start showing it without waiting for the end… and start 
processing data as it downloads … use chuck upload as well

<Marcos> CMN: we have similar use cases

<Marcos> JS: so can you create streams?

<Marcos> AB: yes, we have a stream builder.

<Marcos> JS: it should interesting

<Marcos> JS: we had a contributor who did something similar, but what he 
did was as it progresses, but they grow incrementally until you get the 
blob that has the whole file… the blobs have a fixed size, so it just 
keeps growing… you always get unique blobs.

<Marcos> EU: AB's proposal it sounds interesting to me

<Marcos> EU: is we have a stream object that we can convert to a blob 
would be good, so we can hand it to file writer
Testing

<krisk> 
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0365.html

<euhrhane> [not necessarily convert to blob--possibly we'd just pass the 
stream to the FileWriter.

<euhrhane> ]

<Marcos> KK: we need a more consistent way to do tests… and we don't 
have an approval process

<Marcos> KK: my experience has been that when people start looking at 
tests they start finding issues. An approval process might help.

<chaals> MC: It is difficult to approve tests where we auto-generate a 
ton of them. You can produce lots from WebIDL, and it is time-consuming 
to check each one.

<chaals> ... might be a good idea to look at a test generator, rather 
than the test.

<Marcos> KK: the tests I have seen have not been autogenerated.

<Marcos> KK: maybe we can create task force, somewhere more focused to 
discuss testing

<Marcos> CMN: not sure how we would do this

<Marcos> CMN: our experience is that people who make tests are usually 
not spec people

<Marcos> Wilhelm … introduces himself

<Marcos> wilhelm: we had a meeting last thursday about testing… we need 
to make the tests simple, it would be good to have a standard…. we 
propose using testharnes.js (HTML5 WG is using it). have a look at 
test.w3.org. There are lots of tests there that use the test harness, so 
everyone can see how its done. We need someone to nag browser makers to 
get tests so we don't duplicate work.

<Marcos> CMN: So, do we need a sub group? wilhelm, how should we 
collaborate between Webapps and the Testing and Tools group.

<Eliot> http://w3c-test.org/

<Marcos> wilhelm: please contact us. For visual things, use ref-tests 
from the CSS working group. We are happy to collaborate and provide 
guidance.

<Marcos> CMN: but which group should we do it in?

<heycam> 
http://lists.w3.org/Archives/Public/public-webapps-testsuite/2011Oct/

<Marcos> jG: there is already a mailing list. public-webapps-test-suite ?

<MikeSmith> http://lists.w3.org/Archives/Public/public-webapps-testsuite/

<Marcos> wilhelm: lets figure out what tests there are already

<Marcos> wilhelm: then we can see what tests are available

<Marcos> KK: it think getting a good rhythm going… want to try something 
a little different. If we just do the list, that is ok. But we need some 
more active ways to do things… getting people to talk more.

<Marcos> JS: some feedback we had a while ago, it was harder to write 
tests than necessary. Because of the infrastructure, it made tests hard 
to write tests. W3C tests required more boilerplate than at Moz.

<Marcos> JS: at mozilla, we end up doing it our own way to because its 
easier and faster

<Marcos> JG: yes, there is a bit more work involved with the W3C tests.

<Marcos> +q

<Marcos> +q marcos

<Marcos> JS: the number of tests you get is affected by how easy to 
write the tests

<Marcos> JG: I've had a different experience

<chaals> CM: How does HTML test group work cmpared to not having one?

<chaals> JG: Well...

<chaals> KK: Yes

<chaals> MC: having tests be very easily accessible with an interface is 
really helpful - especially when linked to the spec.

<krisk> HTML started a taskforce two years ago

<krisk> Before that their was no html5 tests

<Marcos> CMN: my experience is the same similar to JG and JS… when you 
pay people, you get people making good tests. But also making them 
easier to write for volunteers, also helps. As KK suggested, we need review.

<Marcos> CMN: it seems like it's an action on the chair

<krisk> today we have a large number of tests across a number of 
features that are implemented in browsers today

<Marcos> wilhelm: writing a good test suite is as hard writing a spec. 
We should have a dedicated person to write a test suite (equal to the 
editor).

<Marcos> CMN: how many person think there should be a dedicated testing 
person for a spec?

<Marcos> [plenty of agreement]

<Marcos> MC: we could make it a requirement that no spec start without 
also having dedicated tester

<Marcos> CM: not every org has dedicated spec people.

<chaals> MC: It is fundamental to have tests, so you can't seperate 
without being able to get a test suite.

<Marcos> JG: this person does not need to write the tests… the person 
would have the responsibility to source the tests.

<Marcos> JG: it does not mean that only one person would write all the 
tests (if any)

<Marcos> wilhelm: if you have 15 specs, you can break up the task 
amongst multiple people

<Marcos> CM: does it have to be a different person than the editor?

<dom> ryosuke

<Marcos> RN: when do you need to involve a testing person?

<Marcos> … discussion… identifying them from the start

<Marcos> DS: that has traditionally been the role of the editor

<chaals> RN: What's the diffrence?

<chaals> MC: It can alleviate the load of the editor

<chaals> ... we need to discuss what to do when you generate tests and 
then the spec changes - how do you avoid starting too early or too late

<Marcos> RN: but we still not clear when we should have tests

<Marcos> DS: for DOM 3, I've requested that people contribute tests… but 
didn't get much back

<Marcos> DS: I would like to have a req that before a spec progresses to 
CR, it should have a test suite

<Marcos> CMN: it seems reasonable as a first step to appoint someone for 
testing.

<Marcos> RESOLUTION: We will insist that when work on a new spec, a 
person be appointed to handle testing

<Marcos> KK: as DS said, we should have something in the process so 
specs can't move to CR without a test suite

<Marcos> DS: part of LC would benefit from a test suite.

<Marcos> http://www.w3.org/TR/test-methodology/

<Marcos> CMN: problem is that it is expensive to produce tests… so, we 
don't want a process heavy way of making tests…

<Marcos> JG: Tests really only come out when people are implementing stuff

<Marcos> JG: implementers who want to have a bug free implementation are 
going to produce tests

<Marcos> CMN: another group to get test from is non-browser vendors 
(e.g., content providers)/.… how do we talk to those people?

<Marcos> JG and JS say there are a few examples of people who have done it…

<Marcos> KK: happy help to set up guidelines

<Marcos> DS: if we have a good way to contribute tests, that would help

<ArtB> WebApps' Test Submission process: 
http://www.w3.org/2008/webapps/wiki/Submission

<Marcos> BS: one of the best ways to learn is by doing. We need really 
good guidelines, so test examples are good. Looking to service providers 
and universities to help use build tests would be good… it benefits lots 
the whole community.

<Marcos> CMN: the public tests can vary in quality

<Marcos> Israel: when is the right point to do testing?

<Marcos> JS: I don't care what the tests are and what they are 
targeting, as long as we get lots of good tests

<Marcos> JG: it's never too early

<Marcos> MC: I agree

<Marcos> DS: who is going to enforce this policy?

<Marcos> CMN: good will :)

<Marcos> CMN: there is no formal policy that we can enforce

<Zakim> Josh_Soref, you wanted to say you're either implementing or 
using someone's implementation or planning to use it

<Marcos> JS: hopefully you are implementing this feature… people have a 
vested interest in the spec and hence produce tests

<Marcos> ACTION: Art and Charles to make a proposal about how to appoint 
a person to be assigned for testing for a spec. [recorded in 
http://www.w3.org/2011/11/01-webapps-minutes.html#action01]

<trackbot> Created ACTION-637 - And Charles to make a proposal about how 
to appoint a person to be assigned for testing for a spec. [on Arthur 
Barstow - due 2011-11-08].

<Marcos> [BREAK]

<jihye> '

<inserted> Scribe: Chaals
API design

MC: we're getting frustrated trying to write APIs because a lot of stuff 
coming out we don't necessrily understand the design patterns - or when 
WAC brings in an API it doesn't look like a Web API and they lose out on 
uptake.
... so we ae trying to reduce the "not invented here" thing by being 
able to get in APIs that match what we think of.
... so we are lookig to create general guidance (rather than formal 
requirements) - what WebIDL gives you, how do you describe throwing an 
excepetion and what does that mean, etc.
... It's a friendly list for editors to find information that is helpful.
... The ideas have all been under development, and effectively black 
magic in people's heads that wasn't available to others.
... Would also encourage people working on frameworks to help us work 
out how we can make things more easily.

RB: To avoid making this exess make-work, when you understand something 
about a design pattern you haven't thought of, just drop in a rough 
email. Don't bother trying to get it right and perfect, dump the half 
idea and let Marcos and me figure out how to explain.

[throwing exceptions, defining events, how to use dictionaries, etc]

BS: Would like to have had a discussion not just about JS/DOM APIs, but 
also other things happening here like things on abstract resources 
handled by the browser.
... We see a number of patterns - trying to understand the rationales 
for that is important.

<bryan> Here is the link to the draft presentation I had prepared for 
the TPAC discussion on this topic. It captures some of the questions we 
had and the objectives for a discussion: 
http://bkaj.net/w3c/TPAC-2011-API-Design-Patterns.html

BS: why is video a tag, why is event-source an API, etc.

AR: Trying to understand if the intent is to capture the way things are 
done, or what we think would be an ideal design pattern.

MC: We are trying to figure it out too...

RB: A large element is a cookbook. Editors do something, someone says it 
is a bad way, they don't wnderstand why and just want to make something 
that works. Goal is to make editing easier

CMN: I'd find the historical explanations useful
... What's the future of this? A note, what?

AR: If we write down what people do now we perpetuate it and that is bad.

MC: We propose this as a note - a useful thing for the community.
... we are trying to help consistency.

AR: Consistency is good.

CM: Helping editors construct prose and interfaces to match what other 
people are doing is good. I agree also that it is good to document the 
rationale.
... it isn't just a matter of people agreeing, because there are real 
disagreements right now.

MC: Yes, we don't just want to codify what people are doing now, because 
we don't want to describe how to do things wrong...

AR: The point isn't to make a normative requirement set, right?

CM: We don't have a general place to do this at the moment...

RB: THere are a lot of people who are here??

Travis_MSFT: Is this less about general API design and more about 
particular things that you want to do - events or callback? what is a 
webby error? ...

RB: Yep.

[examples of different approaches]

scribe: Not sure a document can recommend aright way, but might describe 
a possible set of ways to do so.

MC: Ca Can show examples, and why they did it.

JS: Think this is a great idea. I'd like to know e.g. how you should 
write a callback-based approach and why. I'd love to have more input 
from people who write JS.
... in particular, from more than two people who do the same thing 
already. Take into account beginners, who are not here.
... most important peopl to get input from are not in the room

RB: E.g. JQuery standards group

JS: Right. We should talk to those guys.

AR: I can tell you what to do ;)

Balaji: Good examples are important. We should do this across different 
WGs. ANd there are different groups that have very fdifferent patterns, 
e.g. geolocation.

RB: Yes. People outside this WG don't know or care about working group 
boundaries.

<nvbalaji> Not suresh. I am nvbalaji (nvbalaji)

<nvbalaji> :-)

CMN: I think the TAG has a role here - at least in the structure. I 
don't think we want to palm this off to the TAG, but I think they have a 
role as custodians of these large questions.

NM: I don't think TAG has "the expertise" here, and we don't want to 
repeat other people's work. We don't necessarily have an opinion here, 
but we are intersted in how these questions are resolved in different 
places.
... THere are things that are deep architectural things. When you have 
APIs, over time, you want to evolve things - and you can't install a 
flag day on the web.

MC: You were involved in the "architecture of the Web document" - are 
there relevant lessons from communicating, the experience of doing it, etc?

NM: Web arch is different to architecture documents I have seen. 
Architecture documents in IBM answered specific questions to say "did 
you do this right or not?" Web Arch is more infromal - and is a 
retrospective document, not prescriptive. Tim wrote design notes for the 
web, which found their way into Web Arch (specific "thoughts")
... I think good architecture can be related to use cases.
... Invent good stuff, think about the use cases, think about 
architecture. but the web arch document is very backwards-focused - what 
was important in a running system.

DS: +1 to this - it costs a lot of time and frustration for people to do 
APIs wrong without knowing where they are going. We shouldn't reinforce 
anti-patterns, but ahving a document that says why they are 
anti-patterns and what other patterns could be used is useful.

BS: What I get out of this is "yeah, we need this discussion..."

[kibbitzing on list choice]

<ArtB> Scribe: ArtB
D3E and DOM4 Redux

JR: IE9 implemented 100% of the spec

… think other browsers implemented about ~60% of D3E

CM: so, I think the Editors are OK with making the requested changes

… is that a fair characterization?

Sam: other than IE, who will implement this?

JR: Olli Pettay has been involved
... I don't know about Google

JS: I talked to Olli

… we intentionally remvoved ExceptionEvent

<heycam> [There may be confusion in the minutes at some points between 
CM and CMN. :)]

… Olli is not as concerned about edglazkove cases AvK and Ojan mentioned

… We do implement a lot of the spec

… Not sure if we will implement all of it

… and the parts we may not implement are features that matter

DS: D3E is a subset of DOM4 re the events

… we changed the spec to not have conflicts with DOM4

[ scribe missed James's comments ]

<gsnedders> Subset of DOM4? I thought it was a superset, containing 
additional things like ExceptionEvent.

Ojan: re Sam's question

<jgraham> Have we considered dropping the parts of D3E that overlap with 
DOM4?

… I can't give an official Google positin

<anne> gsnedders, mismatch, if you will

… but there are parts we would implement and some parts we won't

Sam: specifics please

Ojan: there would be a long list

… text input event has an input method

… I don't think WK will implement it

… key and char properties

… are problematic

… but we havent done a detailed analysis

Doug: please send that to the list

Jonas: re taking D3E stuff out of DOM4

… Ojan's list doesn't help with that

Ojan: I expect WK to implement DOM4

Jonas: for the parts that are the same, it doesn't matter

… I talked to Olli and my position is the concern is about the long time 
for DOM4 to ship

<gsnedders> Only if they are word-for-word the same, otherwise there 
might be accidental differences.

… it keeps adding features

Anne: we are removing features

… only event constructors are new

Jonas: what about mutation?

Anne: not there yet

… but they could be

Jonas: concerned about a continuously evolving spec that never finishes

… we need to ship something

… and D3E is done

… My concern is no clear signs of DOM4 actually shipping

… I think we can ship D3E sooner

Marcos: I don't agree

… think DOM4 is in good shape

CM: as Chair, we have a responsibility to ship specs

… I realize some people don't agree with that

… but that belief is not aligned with the WG

… by shipping I mean publishing a Recommendation

… Re Jonas' comments, we need to ship a spec

<gsnedders> One option for mutations events is surely to make them a 
module of their own?

… don't want a bunch of nit picks

<gsnedders> In which case DOM4 is more-or-less done

… that keep coming in

… think the spec is good

<gsnedders> (in terms of getting to a point where LC is possible)

… We could cut stuff out

… by reading the tea leaves of DOM4

… and if DOM4 changes, we can rev D3E

… I don't want to keep going in circles

… that costs lots of time and money for everyone

… for Editors and Implemeters

Doug: the parts under contention are from original DOM specs

… D2E is too old

… If DOM4 parts are better and stable

… and reconcile the 2 specs

… We could drop stuff from D3E if problematic

… and then go to LC

… I am willing to change spec to follow DOM4 where it matches 
implementations

… I can see AvK's approach is useful

… and successful

… so now we change D3E to match

… I still contend a D3E REC is useful

RN: is it possible to drop those parts not implemented or are controversial?

DS: yes, that can happen in CR

… that's kinda' expected

CM: need to agree on what's controversial and what's not

… and that requires drawing a line in the sand

… need browser vendors and others to define what's controversial

… We need to make a decision

… DOM4 is trying to make the situation better

… but we also have people that need to ship product now

… and of course we have the users of the APIs to consider

<gsnedders> One option is to proceed to CR, and see what parts meet the 
CR exit critera, and move from there.

… How important is it to ship a REC?

… Need to define the features as implemented today

Jonas: I don't want to have anything in D3E that DOM4 deprecates

… need to look at EventException

Jacob: I agree re deprecation

… I think we want to move fwd with constructors

… think we need to talk to talk about specific events

… and we can deprecate some events

… We should make sure the two specs are synch'ed

RN: can we drop the IDL interfaces?

CM: we agreed yesterday that WebIDL will be used

Jacob: need to work together to get a list of incompatibilites

… then we fix them

… then we we go back to LC

… There is a lot of feedback since D2Events

… If there are change requests, must open a Bug with Bugzilla

CM: let's ask Anne if he can help with this?

Anne: yes

CM: so Jacob made a proposal?

… Who supports this proposal?

… 15 people supported the proposal

… Does anyone object to that proposal?

… there were NO objections

<Ms2ger> smaug, such as? Apart from the new exceptions, we only really 
have legacy stuff and some things from HTML

<smaug> Ms2ger: many parameters are optional

<smaug> DOM range isn't backwards compatible etc

<smaug> Ms2ger: I agree the changes are usually good

<Ms2ger> Mm, I guess you can say that

<Josh_Soref> Scribe: Josh_Soref

<Ms2ger> No calling in today?

<jgraham> I think it is possible to set that up if you want

<smaug> what is the topic?

<jgraham> Although the evidence is that you don't really exist
XBL2 and Component Model

<scribe> Scribe: Josh_Soref

<anne> how many engineers does it take to dial a number?

<anne> 0, you just ask the hotel staff

AlexRussel: Alex Russel, from Google
... we have a proposal for Component Model
... and there's a belief that there's overlap with XBL2
... we'd like to understand the WebApp's community view on the landscape
... and we'd rather have an either-or and not an and
... I'd like to get a sense of the current implementers' view on XBL2

weinig: Sam, Apple
... we've discussed this a bunch of times
... Apple's iggest concern is the lack of a well formed declaritive model
... it's also a bit disingenous
... to say XBL2 is dead long live component model
... and then to say it's similar and has overlapping goals

AlexRussel: we assume them to be exclusive
... and our view is that they are
... the lack of a declarative model that's fully specified
... is something that we've taken as something
... and we'll work on
... Parser Integration, Shadow DOM,
... what we'll do with behavioral pattern

anne: We'd like Cross Origin
... for things like Like / +1 buttons
... I don't think the goals of cross-origin and bindings
... are compatible

weinig: I think it's valuale to have a component technology for the web
... XBL2 and the new proposals are both two different directions

<weinig> s|weinig|maciej|

weinig: otoh the framing of this
... is XXX
... otoh the new proposals are fragmentary, not specified in sufficient 
detail
... and i'm not convinced they're in the right direction
... i need to see something that looks good, and currently neither looks 
totally right

sicking: my view is that something between xbl2 and component model is 
the right approach
... i think taking xbl2 and using it and cutting things out is more in 
the right direction
... than the proposal i've seen from you guys
... it's hard to see too strong of a comment given the lack of a 
proposal for the declarative model
... even though xbl2 has a lot of complexity

[ Scribe reports that smaug agrees with sicking ]

weinig: i also agree with sicking

dg: I disagree
... because if we do it, we'll end up with a completely different spec
... if we cut things out, we'll have to reinvent the parsing
... we'll have to deal with event forwarding

sicking: i disagree, event forwarding is needed

dglazkov: event forwarding/event retargeting are different things
... the general approach of the component model
... is that you subclass
... shadow DOM is something you get
... i do not think it's a good idea to treeat the component model is 
just a single spec
... because the different pieces can stand on their own

s/..../.../

s/..../.../

scribe: we already have two different specs
... confinement is a problem outside of components
... you want to run scripts confined, instead of just in iframes

s/..../.../

scribe: that said, i think it would be a useful exercise for those who 
believe we should keep xbl2
... to go over it and see if it's doable

<Ms2ger> s/valuale/valuable/

scribe: if they could go over it tomorrow for 30 minutes

sicking: to make actual decisions which we're not at that stage
... we need more concrete proposals
... to have discussions here/now

s/..../.../

s/..../.../

scribe: we'll need actual proposals to make
... decisions

dglazkov: what's the right forum and what's the best format

<Ms2ger> s|s/..../.../||

sicking: brainstorming session if we get the right people
... if we get the apple people, and hixie

[ hixie is behind you ]

sicking: and start sort of drafting some vague proposals

dglazkov: +1

mjs: i like seeing proposals
... two things, about evaluating them
... often it's really hard to evaluate things independently
... without evaluating the whole system design
... whlie people doing the core design work may have thhe whole thing in 
their head in a vauge whay
... second thing is it's important to have proposals drilling out in a 
detailed way
... but when you lay out the full details, you see problems that become 
very complex to address
... and it's hard to give a full review of a relatively high level sketch

[ bridge dialing ]

<dglazkov> http://wiki.whatwg.org/index.php?title=Component_Model

dglazkov: we have a proposal
... it provides a very good overview
... it tries to capture the big picture
... i have gone over a small part of it at our powwow at mozilla all hands
... but i didn't go over the whole thing
... as far as details, i agree, details are hard
... i welcome ideas
... ewe tend to work on this in person.
... it brings certain isolation as most of us are working for the same 
company
... even posting things in public is not enough

s/ewe/we/

dglazkov: and it turns out everyone is busy

dcooney: i agree with dglazkov
... there was a complaint that proposals so far don't have a detailed 
declarative syntax
... and we'll address that.
... i'd like to encourage people to avoid taking some simplistic view
... that declarative and XXX need to be mirrored.

AlexRussel: there is, there's the form element v. xmlhttprequest

<dglazkov> s/XXX/imperative

dcooney: some things just won't be expressable in both

weinig: i certainly can understand not jumping to conclusions about 
individual pieces
... when we saw the demos of what would currently exist.
... it seems that it was working around things with hacks without a 
declarative syntax.

AlexRussel: setting this up as an either or is misleading
... our goal was to design declarative as a sugar on op of imperative
... at least a strong mirroring.
... can you define declarative with the imperative api?

[ no ]

sicking: this is what i disagree with
... we want to have bindings adding to css that are purely stylistic
... things with a different security model that are cross origin

AlexRussel: if you don't have the plat capability
... if you can only do it declaratively
... you should do the archeology work to uncover the primitives and 
expose the,m

<adrianba> s/the,m/them/

sicking: would you say style sheets are declarative sugar on the style 
attribute

AlexRussel: i don't think that's the right question
... they have a different semantic in terms of inheritance
... for bindings in xbl2
... what you're missing is a way to be tied into the application life cycle
... treating style attributes as desugaring
... there's a missing bit of infrastructure
... it's the mechanism in which you're allowed to do i

travis: Travis, Microsoft
... i'd like to +1 the desire to move forward on specing on some 
balances of company's ideas
... there's clearly value in dspecing out ideas outside of the ocmponent 
model.
... i'm interested in seeing that move forward even without a 
declaritive model.

darobin: if there were a brainstorm model,. would you be interested?

mjs: in practice, the declariative/imperative model, which will be the 
primary interface for developers?
... for people believe in declarative, the approach to design is based 
on that
... define that first

<adrianba> s/of company's/of Alex and company's/

mjs: for people in imparative, the approach design's that first
... and make a sugar layer for a subset of the other
... that's the underliying phiulosophical difference
... hopefully once we have specs for this, we can comment on this
... instead of hypothetical "i think this won't work""
... you can't predict if the layering will work unles you can see oth layers

dglazkov: it sounds like there will be a brainstorm tomorrow
... we have some proposals for declaraitve syntax
... if you enjoy half cooked meals
... we're tready to sreve them to you
... the problem is difficult
... what made xbl2 so difficult to spec and comprehend was the decorator 
concept
... the fact that you could ad and remove behaviors dynamically
... i believe this is where we'll fall into despair tomorrow
... i recommend defering that question

<dglazkov> http://wiki.whatwg.org/wiki/Behavior_Attachment

dglazkov: there is a page where i outline th edifference between the two:

[ bad sequence, lag ]

dglazkov: subclassing is a very common thing that happens in many languages
... you add behaviors to a thing by extending it
... decorator is clsoer to an aspect oriented language
... you can create xxx

<Ms2ger> s/tready/ready/

dglazkov: component model tackles element behavior attachment
... and defers decorators

darobin: i'm hearing agreement on seeing more specs and on a 
breakout/brainstorming tomorrow

dglazkov: all day tomorrow?

darobin: there's no one form w3c here
... either it's outside the structure tomorrow
... you take a table and work it out

<heycam> Current schedule for the sessions tomorrow: 
http://www.w3.org/wiki/TPAC2011#Session_Grid

darobin: or you go through channels tomorrow morning and propose
... we're enjoying the fact there's no team contact

[ people discuss the grid ]

darobin: 11:15am?

heycam: i'd like to go to api design
... could we have it at 1:30pm?

[ 1:30pm ]

[ poll, who might show up? ]

darobin: about a dozen people

mjs: i can't be here tomorrow, sorry

darobin: anything else? sXBL?

dglazkov: are we still considering sXBL?

darobin: there's a point wrt Rechartering

mjs: i think everyone has agreed we want to do components
... and the disagreement about the starting point
... as long as the charter doesn't identify the name

darobin: chaals we should ensure the Charter doesn't name the spec
IndexDB

[ People leave ]

<smaug> s/Index/Indexed/

<smaug> is there some kind agenda online?

sicking: it's been almost finished for 6 months
... anyone from Google here to talk about this?
... the only issue i know outstanding is error handling
... i don't know if we have filed bugs
... i can look tat u[p
... those might be more editorial

Israel: Israel from Microsoft

sicking: there's not all editorial, but the ones i see are really small

michaeln: Michael N, Google

sicking: Israel and I talked a bit about it over lunch
... it seem s we might have agreement
... that error events aren't actually fired
... There are two types of errors
... one associated with a request
... one isn't

Israel: and one of those kinds is basically fatal

sicking: and we never arget ererors at the transaction

Israel: hopefully developers understand what they can do

sicking: that's actually drafted in the spec
... we should clarify that we're talking about that in this thread
... and confirm people are ok w/ that solution
... beyond that, we could go through the buglist
... it's pretty simple stuff -13 bugs

darobin: anything we can close is good

sicking: i suspect most require changes to the spec
... but we can coe to agreement
... bug 14199
... just a bug in the spec
... bug 14201
... - mention of version change request, which is renamed - trivial change

darobin: that's editorial
... bug 14318
... - that's important to mozilla
... bug 14352
... - idl marking requirement
... editorial
... bug 14384
... - that's an interesting quetion
... currently we throw if readystate isn't done if you try to get result
... so you can't get the transaction during upgradeneeded, which is bad
... - we should set readystate to done
... - not sure if that's the right fix
... we could do something special in this case
... it's the request from an open call

Israel: there is a transaction, locking the whole database

sicking: yes
... what should ready state be?

<scribe> ... done even though we haven't opened?

Israel: done seems fine

sicking: bug 14389
... - i wanted alex here
... we have two callbacks in the spec in the sync api
... the two way sfor creating a transaction
... currently they're [functiononly]
... so you can't pass an object with a handleevent or similar
... i have no opinion on that

[ jonas explains to alex who just returned to the room ]

sicking: is there value in supporting passing objects?

alexrussel: the object passing protocol is strange from a design perspective
... you could have an object that handles lots of things
... the question from hj is "what's this?"

s/hj/js/

darobin: that's the benefit of using an Object

alexrussel: I think passing an object whose members are named by the event

Josh_Soref: the idl lets you pick the function name on the object

sicking: this is part of the indexed db spec
... you pass it a callback for the transaction
... we can support function, or function-or-object

Marcos: looking in general how JS is used
... many people don't use the object form

<smaug> =FunctionOnly should be removed from the spec

mjs: to make this clear so we stop talking about handle event
... can you give us the name of the name on the callback object

darobin: what is the color of the bikeshed?

Marcos: it's called handleEvent

sicking: let's pretend we renamed this to transactionStart
... it would be a single function name, since we only do one thing

AlexRussel: if this is the beginning of having well named properties for 
callback objects, that's great

[ scribe repeats what Smaug said ]

darobin: I agree
... it should be transactionStart

mjs: WebKit has usually not done the FunctionOnly bit

[ Good bikeshedding, we picked a non black color ]

sicking: bug 14393
... i think i've already fixed it
... bug 14404

<smaug> FunctionOnly is always a spec bug except with onfoo event listeners

Israel: this related to not knowing which version you were working on 
during an abort and wanted to do an upgrade
... this related to an exception/event type not? having a version or 
something

[ No one seems to really remember tihs ]

Israel: inside upgradeneeded
... with an optional parameter, how would you get the version?

sicking: database.version in the upgradeneeded or the callback

Israel: if you aborted it, and you're outside the upgradeneeded

s/tihs/this/

Israel: I think this predates an [optional] paremeteer

s/parameteer/parameter/

sicking: if you fail to open
... which is where an upgradeneed happens

Israel: I think you can close the bug
... i don't think we need it anymore

sicking: we need to specify something, because it's unclear in the spec
... bug 14405
... - i fixed that
... bug 14408
... - this is based on a usage pattern we saw
... as things stand now, if you open a cursor and in the callback and 
you do a bunch of things, and expect the cursor to progress
... having to call continue at the end is hard
... as soon as you call continue, getting .key/etc will trigger an exception
... we propose that once the cursor has recieved its first data, it 
won't throw

Israel: so it's just caching data?

sicking: this is because of request objects

Israel: so this is different than calling continue twice?

sicking: yes, that still throws

michaeln: what happens when you call continue on the last cursor?

sicking: either we make it start throwing, or we can leave the values as 
they were

michaeln: this came up recently in code review
... and the response was "oh, i don't think tha'ts specified"

sicking: in general, the spec tries to agressively throw

michaeln: where you're changing the behavior of aggressive throwing
... it needs to be fleshed out

sicking: i think i offered to fix this bug

i/start throwing/... there isn't a reference in the callback (it's 
null), but you can have another reference to it elsewhere/

sicking: bug 14412
... no brainer, we should do that
... bug 14441
... - just outdated, should remove that note, editorial
... bug 14488
... - missing annotation
... that's it!
... what do we return from delete operations?

Israel: I'm ok with not returning anything.

sicking: the spec says to return true if it deleted something or false 
if there's nothing to delete
... in some casw, that would be useful
... this is asynchronous

s/casw/cases/

sicking: this could be slower to implement
... and since we don't know if someone's going to use it, we already 
have to dig it out
... the speed cost is totally implementation specific
... my preference is to return nothing, to be safe
... you can always get the information, although it's probably slower - 
by calling count first

Israel: we're ok not returning anything
... as long as you end up in a success handler
... the issue was, what happens when you're deleting a range
... and you can't delete all of the range?
... and we agreed to throw two kinds of errors

sicking: if you fail to delete everything, you always have to revert, 
since all actions are atomic

Israel: one thing that would be great
... we started putting out there a test called LAteral
... we'd like to get feedback from all implementers to see how 
interoperable we are
... i believe the set of tests are for the old set version

sicking: we already landed the change

Israel: we'll try to revise the tests
... open-with-version is the new api to replace set-version

[ That was answered for the Scribe ]

sicking: unfortunately, all of our tests rely on the error event
... and they use generators
... JS Harmony generators

Travis: you can always stick things into the submissions folder

s/Travis/Travis_MSFT/

sicking: we'll need to go through our tests and rewrite them to not use 
generators, which are convenient to our test writers, but not portable

adrianba: it'd be helpful if you submitted them so we could see coverage 
and avoid duplication

darobin: and someone might magically do the conversion for you
... i'm hearing whispers about LC

sicking: we might be able to do LC this year
... we need to fix these bugs, but they're not much work
Mutations

RafielW: from Google
... I'm curious to know if anyone from Apple/Microsoft has an opinion

Travis_MSFT: Travis, Microsoft
... I'm reading it right now

weinig: Sam, Apple
... in a similar vein, we've been working on other things, and it hasn't 
been a high enough priority
... it's been moving pretty quickly and doens't seem bad
... it's good if it ties in with undomanager

s/doens't/doesn't/

Travis_MSFT: this is MutationObserver?

<anne> wait is this about mutations already?

RafielW: yes

[ Group apologizes to people not present ]

[ we break for 10 mins to let those 3pm people to arrive, please arrive 
promptly ]

<Ms2ger> [ Threats of hunting down people who are late ]

<Ms2ger> [ Robin, be warned ]

<Ms2ger> OH: I don't believe in the internet

darobin: it's 3pm, we're starting

Travis_MSFT: Would you like to tell us about MutationObservers

RafaelW: ok, so an overview
... the intent is to be a replacement for DOM Mutation Events
... the fundamental difference
... is mutation events try to project an abstraction
... that things are going to be dispatched synchronously
... that turned out to be problematic for a number of reasons
... MutationObservers are different
... you can register an observer to express an interest in a certain set 
of mutations
... and you'll get a list of things that have happened
... it's a batched list of things that have happened
... since the last time you were called
... the other interesting part is the timing of delivery of mutation records
... there was a pretty long discussion on Public-Web-Apps about this
... the people discussing this

<Ms2ger> s/Public-Web-Apps/Public-Webapps/

RafaelW: arrived at what smaug coined as "the end of the microtask"
... for the delivery of mutation events
... it means mutations are delivered at the end of the outermost script 
execution
... if outside such a thing, at the end of the current task
... as part of the single Turn, before painting
... otherwise you see artifacts

weinig: can that be defined in terms of the event loop?

anne: currently painting happens just after Task completion

RafaelW: currently painting has a gaurantee (ignoring Modal dialogs)
... but you may get called before the end of a task
... if a synchronous event is handled
... say for mouse down
... and mutations happen as part of those handlers
... then you'll get something delivery then as part of that outermost
... invocation

sicking: my understanding of when it's defined to fire
... for example the Load event for XHR
... it fires at the end of each event handler
... let's use a click event handler
... it fires at the end of each event handler on each event target
... it happens multiple times during the call to dispatchEvent()
... so if you click on an element 3 elements deep
... you call on 2 elements in capture
... on target
... 2 on bubble
... You get it twice for each thing, potentially, but only if there are 
mutations
... the reason for this
... smaug was concerned that if we do it at the end of a task
... if each event handler is independent
... and doesn't know what one might do
... invluding doing a sync XHR

s/invluding/including/

scribe: during one of those, we'd need to fire these there
... there's a risk of an actor

anne: what if an actor calls showModalDialog

sicking: yes, but it means you can only shoot yourself in the foot

anne: that's acceptable

RafaelW: smaug are you there?
... can you explain more?

smaug: the idea was to encapsulate the mutation
... web pages cannot detect what is a task

<anne> ^^ "that's acceptable?"

smaug: you may dispatch several events during a single task
... it's always when a event handler returns or a timer returns

weinig: does that mean that every new api we define we'll have to define 
microtasks
... or do we infer it?
... specification-wise?

sicking: specifcation-wise, it would probably be nice if they did
... but it should be pretty obvious
... any time you call into the web page
... that isn't inside another callback

mjs: in that case, it might be nice
... if this concept was codified in some more explicit way
... we do have the concept of calling into script and having it call out
... it seems we're in agreement in what it is

sicking: when i spoke to Hixie , he said there was something like that 
in html5
... used to figure out security for call stacks
... but yes, it needs to be codified

[ Hixie is no longer behind sicking ]

sicking: there's special handling around
... MutationObserver callbacks themselves
... if you have 3 observers
... and you make a mutation to the DOM
... and #1 makes a mutation

[ Sicking will write this in ]

rafaelw: my mental model
... is the mutation observer maintains a pending queue to be delivered 
to its observer
... and when it's called to deliver, it delivers what it has to its observer
... and that observer can create work to be added to all observers' queues

<sicking> if you have three observers and a modification is made to the 
DOM, then we first call the first observer, then the second second 
observer. If the second observer mutates the DOM, we'll recall the first 
and the second one with just the second mutation, and then the third 
observer with both mutations

rafaelw: and the system loops around until it empties its queues

sicking: everyone will eventually be notified
... and there's no inner looping
... we'll append and create larger loops

mjs: can you create an infinite loop with 2 listeners?

sicking: even a single listener can create an infinite loop

<dglazkov> s/mjs/weinig

rafaelw: what would happen with current mutation events?
... you explode the stack
... that coding error
... here is just an infinite loop instead of exploding the stack
... we talked about a fixed limit on going around
... the advantage of exploding the stack
... is that you can see a stack trace to understand what went wrong
... hopefully developer tools will evolve to help you debug the infinite 
loop case here

mjs: there would be a way to avoid starving the paint cycle

[ Scribe summarized poorly ]

mjs: it's possible to make a design
... where you don't have an arbitrary fixed limit
... but you don't starve the event loop if you have a programming mistake

rafaelw: we talked about that
... there are legitimate uses for going around the horn a couple of times
... and then let things settle down
... comes from the model driven use proposals

s/proposals/proposal/

scribe: we were asked to slow down and look at the use cases

rafaelw: imagine you were using a JS library to do templating
... and used something like jQuery to do a UI
... and it wants to go decorate the page w/ more DOM
... and you used a constraint library to manage forms
... so the templating library might produce more jQuery stuff
... and the jQuery stuff might trigger more work for the templating

mjs: that seems like a Use Case where it's easy to create something that 
never terminates
... i agree it enables you to do things you could not otherwise do

ojan: Ojan, Google
... as long as we agree
... mutations during one of these callbacks should get delivered eventually
... this error will either result in a hang, or burning cpu indefinitely
... i'd rather the hang
... rather than burning cpu
... i'd rather a limit and an error

rafaelw: i mostly agree
... i just don't want to create a situation where a developer doesn't 
know if he'll run before a paint occurs

mjs: you have the situation where each piece of code has observers
... you need to globally analyze to determine if it will finish

Travis_MSFT: they need to be interdepent
... you could get into an infinite loop
... if jQuery included things which the validation system depends on
... which depends on the third component
... but in most cases, i don't think that will happen
... you might have a queue of 3 or 4

mjs: the loop was claimed as a UC

Travis_MSFT: i agree, but disagree on a hard limit
... the distributed UC is potentially difficult

ryosuke: we already have this problem with the current system
... i don't see this as introducing new issues

mjs: given how bad mutationevents are
... i don't support "no worse than them" as justification

weinig: yes there are problems, yes this makes things better
... if we could avoid more problems, that's better

darobin: the situation you've described is a corner i've painted myself 
into many times

weinig: in the end, those risks are going to be minimized by something 
XBL-ish
... or component modelish

[ laughter ]

mjs: there's really 3 basic things for this issue
... 1. repeatedly cycle until all queues are empty
... 2. have a fixed limit
... 3. at some point, delay delivery to avoid starving the event loop
... this should be on the mailing list

ACTION rafaelw to send how to handle single pass not emptying all 
mutation queues to the list

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

[ anne asks a question ]

anne: call dispatchEvent() from code
... where does that get trigger the mutation observers?

sicking: the outermost thing is always a callback
... which is a microtask
... if you call dispatchEvent() in there,
... the mutation observer calls back from the end of the outer microtask
... it's like a function call

anne: tasks that are queued are special?
... yes, they are outermost, so they're special

rafaelw: are you concerned, or not understanding?

Travis_MSFT: i'd like the spec describe the scenarios clearly
... perhaps even so people can visually see

ojan: and if sicking could recall the thing Hixie said, that'd be good

smaug: i need to finish the implementation first
... to decide if it's good

darobin: does this go into DOM4?
... does anyone care?

<Ms2ger> I do

<Ms2ger> As mentioned before

<anne> you can edit it :)

ryosuke: i've heard that they relate to DOM4 and should probably be there

anne: i do think it should be in there
... because every other spec that intergrates should work with it

darobin: we seem to have violent agreement there

<Ms2ger> I'm in violent agreement with anne :)

darobin: anything else to discuss?

Travis_MSFT: do these observers include stylistic properties?

sicking: most stylistic changes don't directly do this
... but many times you trigger a style change by setting an attribute or 
inserting something, which would itself be an observer notice

rafaelw: there's an attribute filter

darobin: perhaps there should be something specific for a specific class 
value

rafaelw: we agreed this is probably the 80% use case
... there was an earlier proposal from microsoft called watched-selector

weinig: i want to echo that point
... the extra class list on element was the favorite thing
... special casing class might be valuable

ojan: i really liked the watched-selector proposal
... it's more generic, over a selector instead of just a class list

s/watched/watch/

<anne> watchSelector

s/watched/watch/

scribe: what i like about this is that you can implement watchSelector 
on top of this

rafaelw: it's on my list to open source a watchSelector reference impl 
on top of this

darobin: anything else?

[ No ]

[ Break until 4pm -- for server sent events ]
Server Sent Events: Push

[ darobin bryan will introduce, it's up on the screen ]

bryan: I sent to the list a link
... 2 years ago
... at TPAC here
... We had a discussion at the HTML WG about connectionless push
... the text at the time was fairly generic
... the ability to use connectionless methods
... not having to maintain keepalive
... the intent in that spec, still informative
... a list of things that might occur in the process
... this spec
... I've been involved in OMA since 2000
... involved in the push work in OMA since then
... we recently completed work within OMA
... this api is enough to form the basis of an extension to event source
... it provides a way to use SMS
... as an extension to http push
... events are passed up to the application, in this case, the OMA runtime
... when it's advantageous to save resources
... it's possible to coalesce these into a unified message
... event source didn't define these because they were out of scope to 
the spec
... I have a diagram here showing how apps could be deployed

[ http://bkaj.net/w3c/eventsource-push.html ]

[ bryan describes the diagram ]

[ The diagram is: http://bkaj.net/w3c/eventsource-push.html#introduction ]

bryan: this doesn't modify the signature of Event Source
... down the road, we might create a persistent registration
... to let events wake up applications
... you have the desire to connect two new barers through uri
... you can use a registered urn that defines OMA Push
... within the IMS framework
... events are delivered using the same model as Event Source
... although the event type is sent to SMS for SMS
... and OMA Push for OMA Push
... you don't get onMessage() since these are not message events
... with OMA Push
... the simplest way was to create a sequence of strings
... so the application can receive all of the data as a single event 
using the event stream concept
... in this case, i pulled out the xml document, the url, and the text 
message, and present it
... for sms, the sms text message gets put into the event and delivered

[ http://bkaj.net/w3c/eventsource-push.html#fallback ]

[ bryan describes second diagram ]

[ http://bkaj.net/w3c/eventsource-push.html#proxy-fallback ]

[ bryan describes third diagram ]

[ http://bkaj.net/w3c/eventsource-push.html#constructor ]

[ http://bkaj.net/w3c/eventsource-push.html#event-processing ]

[ http://bkaj.net/w3c/eventsource-push.html#event-stream ]

[ http://bkaj.net/w3c/eventsource-push.html#security-considerations ]

[ http://bkaj.net/w3c/eventsource-push.html#same-origin ]

[ bryan mentions Widget contexts but glosses over it ]

bryan: developers need to consider filtering for security considerations
... just as in web messaging
... accepting "*" is the responsibility of the application choosing to do so

[ http://bkaj.net/w3c/eventsource-push.html#application-security ]

[ http://bkaj.net/w3c/eventsource-push.html#privacy-considerations ]

jcantera: Jose Cantera, Telefonica
... how do you intend to progress this?

darobin: charter wise, it's in scope to this group
... if this group is happy to do it
... do you think it would make sense
... one good thing is that it lets web apps have the same notifications 
as native apps
... and it shields web apps from complexity
... would it make sense to hide the distinction between OMA Push and SMS?

bryan: i considered it
... but, how do you deal with different framing formats?
... in OMA Push, you can deliver any content type
... the headers are important, you need to know the mime type
... those elements are important
... for a server to provide to the app
... i couldn't figure out how to combine that

weinig: what mobile OSs support this?

bryan: I prototyped this in Android
... I believe almost any OS in a smartphone class
... allows a developer to attach to network sources
... and allow someone to act as an agent for this
... in mid tier devices, that tends to be more complicated

lgombos: Laszlo Gombos, Nokia

[ Lost, sorry ]

sicking: we talked about this at Mozilla
... but we created something very different from this
... there are two unfortunate things here
... 1. I'd like to hide whether messages are from TCP/IP or SMS or OMA Push
... (I don't know anything about OMA Push)
... - it feels like the goal was to expose OMA Push

<heycam> anne, no it's at 4:30

sicking: The goal at Mozilla was ... How do we expose SMS over a channel 
that isn't TCP/IP?

s/anne, no it's at 4:30//

scribe: the other part is requiring permission from the user
... that severely limits how many users allow that
... if it's a little bit sensitive, people are still rightfully worried
... people press no, which is better than just pressing no
... we were hoping to provide something simpler/safer

bryan: there could be prearranged trust relationships
... but it would be better for the user to have already trusted the app 
and not overburden them with prompts

darobin: what sicking was getting at
... is providing an *always* safe subset
... to avoid getting permission
... this is more powerful, and "easier in terms of security"

bryan: "how do you make this transparent?"
... look at XHR, the agent says "i want / i'll take these mime types"
... if we could take event source and say "i can accept these mime types"
... that would let me decide if it was safe to deliver it
... because i didn't want to change event source, i couldn't do that

darobin: i think that's an option on the table
... i'm hearing interest in doing something around this
... would anyone object to the group working on this?
... it's in charter already

[ Chatter ]

sicking: this feels different enough from what we talked about at mozilla
... it feels like a different deliverable
... if we can solve it by just adding a header
... great

shepazu: would you be comfortable having a line in the charter scoping 
it more tightly?
... why don't we three right a deliverable line for the charter?

darobin: to avoid waiting for rechartering
... we should agree on a scope
... bryan it'd be good if you could send use cases
... sicking, it'd be good if you could send something

mjs: weinig asked earlier if this is implementable onn iOS
... i believe as presented, the answer is no
... iOS doesn't give applications the ability to receive SMS
... to me, that says that a design that does not force the web page to 
choose a transport would be better

bryan: i've said "any available barer would be good"

darobin: ok, based on the email you all send, we'll scope the work
WebIDL

heycam: helo

s/helo/hello/

scribe: In this session, I want to let people bring up issues
... and discuss how we might go about testing
... and third, what are the time frames for implementers (smaug asked this)

AdamBarth: Adam Barth, Google
... do you mean consume the syntax?

<dom> Thread on testing Web IDL

heycam: I don't mean specifically that, perhaps just conforming to its 
behavior

weinig: one thing we talked about in terms of testing WebIDL
... is to test it in terms of specs that are speced in WebIDL
... for instance Canvas
... uses ovberloading
... s/ovberloading/overloading/
... and things like prototype chains
... testing people's implementations of generating code, i don't think 
it's worthwhile
... you could hand write all the bindings, and still be compliant

heycam: i agree, that's the only reasonable approach
... i think someone could come up with a set of properties for testing

mjs: the way WebIDL is written, it's targeted at spec writers, not 
browser vendors
... it creates an indirect relationship
... indirect testing through testing of other specs seems the only way 
of testing it
... which unfortunately creates a circular dependeny for progressing on 
the REC track

s/dependeny/dependency/

<dom> [I don't think see why this would be circular? surely we *can* 
create tests for specs that aren't in CR yet]

weinig: we always do that when we test XHR, we test JS

mjs: yes, we do

<dom> s/think/see/

jrossi2: in particularly
... when you test foo-spec, you test webidl

Travis_MSFT: I agree
... and as we march to LC, we need to mark things as AtRisk

darobin: we should just kill it

heycam: and the only one is modules

weinig: does that include namespace objects?

hheyyes

s/hheyyes/heycam: yes/

AdamBarth: you can look at the specs as testing it

heycam: yes, but it's harder to test automatically

darobin: things written with ReSpec are pretty easy

AlexR: Alex from Google
... i'm not sure if this is the right forum for this
... i think the entire java language indings should be dropped

s/indings/bindings/

scribe: second is there are several instances where webidl doesn't serve 
JS well
... 1. a TC-39 meeting
... several months ago
... interface objects which are reified
... do not act like function objects

<gsnedders> One option for WebIDL testing is some sort of tests designed 
to be run in a browser-specific way against the interface generation

scribe: do not behave normally, they aren't callable

[ scribe lost thoughts ]

heycam: I agree with this
... it's unlikely authors will be doing 'throw typeerror'
... things which are unnewable
... things where it doesn't make sense to be able to new them

<anne> new Math()

AlexR: i take the concern
... it's a risk
... the idiomatic way of doing that in js
... is mixins

<anne> (gives a TypeError)

AlexR: the artifact way of doing that would be still newable
... the reality is that today, webidl doesn't specify something 
"reasonable" that could be impleemtned yourself in JS

weinig: that's not necessarily the goal of WebIDL
... the goal of WebIDL is to define how things are implemented today
... and how they should be impleemnted

AlexR: thenI suggest webidl is mischartered

sicking: javascript doesn't have a way to subclass things other than Object
... fortunately, almost everything is Objects
... I know you suggested something using Object.call
... but I didn't hear any inmplemetners interested in doing that
... and it seemed like something for TC-39 to do

AlexR: i should put on my TC-39 hat
... and note that this discussion was something that happened @ TC-39
... and brendan and I agree that everything you can do to an interface, 
should be newable
... and yes, Arrays are odd
... and you sdhould throw things back at uws
... and there are things in ES6, proxies
... which should address it

sicking: what acts as normal JS is a matter of definition
... for example, the array class, and even the string classs
... has built in behavior and doesn't allow you to subclass
... and we're following those models

AlexR: you're still failing
... since your objects claim to chain to Objects

sicking: but Array claims to chain to Object

AlexR: but everything that WebIDL defines has intrinsic behavior

sicking: but that's how it works
... the fact is that TC-39 hasn't solved this problem for any of these 
things
... it's actually more, bz had examples

AlexR: Math is an Object, not a Function

heycam: In the Spec, they are all Function objects, they are defined 
such that when called they throw type error
... which you can do in JS

AlexR: do we still have a separate constructor property in WebIDL?
... throwing by default is a bug

sicking: moving beyond low level semantics
... heycam wrote an example, "new Node" doesn't make sense

mjs: every DOM object that's an object is a specific Subclass of Node

AlexR: but that invariant is controlled by AppendNode

<heycam> The spec says "Interface objects are always function objects."

sicking: but if it's several weeks of work in order to do something 
which no one can do anything useful with, then it's a waste of time

weinig: what's the argument for making node

sicking: all the intrinsic behavior of Nodes is based on which Node 
subclass it is

AlexR: then calling it and newing it throws

heycam: is it worth it to handing back a non useful thing?

Travis_MSFT: the answer is no

AlexR: i'm not saying that you should turn off the ability to new/call
... i'm asking you to turn off the default

anne: then you'd require a lot of specs to change most of the specs

AlexR: i'd argue that for html element types, it's mostly a bug

jrossi2: no, there's more than one interface per element

anne: because the tags all share an interface

AlexR: so you can't create a tag name
... you haven't thought about it hard enough

anne: we have thought about constructors a lot, especially because you 
brought it up

mjs: there are two separate issues
... one is New

<anne> wrong or not, without use cases this is not going to fly

mjs: and the other is subclassabilitiy
... in js, only Object supports Subclassing

[ mjs and AlexR argue ]

mjs: you should fix JS first before we change

AlexR: we have misfeatures in DOM based on document.createElement

mjs: the goal of WebIDL is to describe the actual semantics of DOM 
bindings and to get browsers consistent
... it is not the goal of WebIDL to transform the philosophy of how DOM 
bindings are built

AlexR: the issue of default, shouldn't be the way of forcing the default
... because as anne says, people will just put no constructor everywhere

s/AlexR/heycam/

anne: that's makework

AlexR: creating an instance ..
... in the same idiom as anything else i can in that system

weinig: that's something whicih as mjs said

s/whicih/which/

AlexR: will there be a WebIDL version which changes this?

darobin: no

[ We are at an impass ]

[ Should we drop Java? ]

heycam: oh, i didn't respond to that
... maybe
... if we particularly don't care about other bindings
... and i'm sure AlexR would argue we shouldn't

<gsnedders> I keep on grimacing everytime subclassing is mentioned… 
because JS doesn't scarcely has classes. :\

heycam: should we actually alter WebIDL to reflect something closer to JS
... that is something to consider, but it would take some time to do

Marcos: have you done the bindings for WebIDL in java?

heycam: one project I'm involved in has a Java based DOM

shepazu: i wanted to talk about process very briefly

<gsnedders> Does it look as if anyone will have met CR exist criteria 
for the Java bindings by the time they have been met for the JS 
bindings? IMO that's the relevant matter.

shepazu: dropping Java would mean we don't need 2 java implementations 
to get to REC

<gsnedders> The Java bindings are fine provided they don't hold up the spec.

<gsnedders> (They can always be split out into a separate spec)

mjs: getting two interoperable implementations of java bindings to test 
all of the features of webidl
... would keep the spec from REC forever

shepazu: the Staff view on process
... is that if for each feature we have 2 specs in CR

heycam: the plan is to only have 1 spec consuming some of these items

shepazu: we can be fine about that
... don't let the process for a normal spec drag us down
... we can come to an agreement on the exit criteria
... we're flexible on how we judge the passs criteria

<gsnedders> Can someone ask what the staff view is on impls of the bindings?

mjs: i think we need actual implementations of specs using this feature
... part of what we're evaluating is to ensure that all of the details 
of what it says happen are actually practical/possible

<dom> (I think Java bindings should be split into a different document)

weinig: i had a bunch of questions
... 1. should long long stay in the spec? given its wierd behavior in 
javaascript
... given the inability of js beingable to represent numbers consistently

heycam: the issue being numbers in js over 2^53 get squished into a double
... we talked about creating a class

anne: it's used in progress events

mjs: the loss of precision happens in a javascript parser
... it's more of an issue if we lose that detail in a movie
... the progress events of loading a movie from xhr
... i'm more curious about your opinion

<gsnedders> bigints should be readded to WebIDL after they're in ES

<anne> Josh_Soref: I worry about data loss with this

<anne> Josh_Soref: nobody else worries about it :(

<gsnedders> (i.e., they should be removed in the short-term)

<anne> (roughly what Josh_Soref said)

mjs: 2. should we treat an undefined value for a key in a dictionary the 
same as non existing
... that would be fine with apple, especially if mozilla is ok
... what we do currently is inconsistent for our dictionaries
... etierh way sounds fine, it's usually a programmer error

heycam: sicbrought up cases like that where you deliberately get 
something as undefined

mjs: so that sounds like a use case

heycam: sicking said it's consistent with missing arguments to a function

<mjs> s/mjs/weinig/

s/sicbrought/sicking brought/

heycam: we're making the argument that people compare to argument 
instead of checking

<gsnedders> I think someone needs to look through ES and see where 
[[HasOwnProperty]] is used and where undefined is used

[ see brendan's argument on list? ]

weinig: the other one discussed this week is remove FunctionOnly for 
callback
... implementers have been inconsistent wrt how they use that

heycam: this might be a case where using interfaces resulted in
... creating an object with the property called handleEvent

weinig: i was actually saying allow both in all circumstances
... it's not like we can make addEventListener handle this

heycam: i did it as the default

jrossi2: i found the legacy handleEvent all wierd
... and developers would like to support it everywhere

weinig: in webkit, we allow both

anne: it is defined as Callback FunctionOnly InterfaceObject
... i think it's removed everywere except onFoo

weinig: WebKit allows it everywhere, so

Travis_MSFT: I'd like to point out that in my years, i never heard of that
... i'd rather default to FunctionOnly

AlexR: my preference would be that if Object style is supported
... is that we attempt to allow same name as event name in addition to 
handle event
... so that you can have different colors
... handleEvent is the thing that doesn't do nicely for all event handlers

heycam: if that's the direction we want to go, then we need to support 
Object style
... so you want to remove FuinctionOnly from the spec so you can only do 
both

weinig: i didn't realize that hixie was using it for attribute event 
listeners

heycam: i could inroduce function to actually mean function

anne: we could add eventhandelr for that

heycam: i'll make the change about allowing typedefs to put some 
extended attributes on a type so whenever you use a typedef you get the 
attributes from them

weinig: next...
... i ask this every time i see you
... do people/do other specs use Sequence, and Array?

heycam: now there are

weinig: the next thing, an implementation issue
... is iteration order in for-in of properties on interfaces defined?

heycam: we were trying to defer to TC-39

weinig: TC-39 doesn't define them for host objects
... in webkit, it's a random order

<gsnedders> Does ES5 not define them as undefined for host objects?

<gsnedders> Like, does the definition as undefined not apply for all 
objects?

weinig: i've not heard of any bugs regarding iteration order

Travis_MSFT: yes, we've heard of bugs
... we end up breaking them every time we ship IE
... it doesn't break many sies
... more often than not, it's a testcase
... i would not want them to be defined, because it would be 
particularly hard
... in the spec, there's some mention of ordering
... named and indexed properties

weinig: pragmatic question
... ordering/lookup
... on Window, in the browser
... ... are you comfortable with the hooks on Window
... in webkit first look at the this, and then look at the that, and ...
... there are multiple catchalls that have to be iimplemented in order
... does anyone know if that's speced anywhere?

heycam: yes, between a combination of things in HTML and WebIDL, it 
should be completely defined

jrossi2: correctly?

heycam: there's a bug that lists the order, and Travis_MSFT checkked it, 
and it didn't seem to hit any problems

weinig: it seems like we need lots of test cases for it

Travis_MSFT: i'm waiting for firefox to implement that part of the spec 
(sic)

weinig: the only problem we could hit is "var location;"

s/sic/sicking/

heycam: one question for people
... the approach of having idl attributes mapped to accessor properties
... there's an issue Travis_MSFT identified

<heycam> assigning to Element.prototype.onsomething

heycam: there's an issue travwith an old version of prototype.js breeaking

<heycam> since on* handlers are now accessor properties on the prototype 
that throw if their this object is wrong, this was a breaking change for 
some sites

<heycam> where the previous implementation was to have those properties 
as data properties on the instances rahter than the prototype

heycam: because it checks the this of something
... are people happy with that approach?

Travis_MSFT: yes
... i particularly value it for overloads
... it's easy to replace functionality when you need to

trackbot: yes

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

s/trackbot/Travis_MSFT/

weinig: yes, no issue
... we're worried about performance

AlexR: array.length has two sides
... it's a getter/setter pair
... that can be modeled as getter/setter today
... second, if you write to an index property beyond current length, 
there's a magical put
... shrinking can be repaired
... growing requires morework

weinig: will length be moved to the prototype be moved to use getter/setter

AlexR: it isn't clear how it will be resolved

heycam: earlier in the discussion, we brought up the idea with a more JS 
focussed thing which might replace WebIDL
... not right away
... we didn't have people chime in

[ what would it look like? ]

heycam: something where the actual constructs in JS would sound like JS

darobin: why not use JS?

heycam: because it wouldn't be very concise

mjs: javascript isn't very good for doing that

Travis_MSFT: it's a tricky thing to contemplate
... if you contemplate things the way ECMA does it, you have to be more 
verbose
... on the other end of the thing, you
... it might be an interesting exercise, but i'd like to finish webidl first

mjs: there's some value that webidl is somewhat decoupled from js
... js is the only langauge that's relevant for api specs
... maybe someday every browser owill have python or dart
... if it does, then we will regret it if we define things too tightly

<heycam> Josh_Soref: one of the things which DAP was looking at was the 
ability to specify SOAP replacement

<heycam> berjon: json-rpc using webidl

AlexR: having designed DOM for DART, the right interface will be a new 
way of doing things
... we wound up doing something WebIDL

<heycam> Josh_Soref: they wanted to define an API for things where the 
implementaiton might not be a host object, it might be JS

<heycam> ... but they want to define it in Web IDL

<heycam> ... and in doing that, we were toying with the idea of writing 
a WebIDL to JSON binding

heycam: you're talking about using WebIDL to define a ReSTful interface
... i haven't seen a lot of discussion about that
... outside a bunch of people mentioning it on the DAP list

darobin: it's actually feedback from webkit that brought this up iniitally
... define a mapping to json objects
... and define a mapping to json ipc
... it would be defined separately
... the way forward on that, is that i'll finish my JS prototype of it
... and see if it flies or crases

AlexR: there is a value in having a base description of what the apis are
... in most implemenetations those are in C+++
... and those will correspond fairly closely to the IDL
... but at the same time, having something that is too close to C++ 
doesn't serve JS very well

mjs: in webkit today, we generate mu;multiple bindings from idl
... they are just used ffor portions of the api exposed
... ObjC, C++ bindings, mapping to various frameworks
... possibly Python and Gobject
... in some cases, people haffve specifically mentioned a desire to 
align with the relatively well known JS APs
... as a value relatively close to the JS for users of their language
... there may be value for a single interface description with mappings 
to languages

AlexR: mappings doesn't mean design centered
... if we are designing a multilanguage thing
... then we have a responsibility to all of them

darobin: i think that's a straw man
... we are designing w/ js very much
... as much as i'd like to see a v2
... we're not going to change the course very much
... if you want a v2, bring a sketch

heycam: a bunch of things are collapsing number types or renaming some 
keywords

mjs: the number types are sueful because they define error checking at 
the interface between the js interface and the underlying implementation
... having a single number type would require each spec to explain what 
happens when one passses a non interger
... the case of i only accept integers in this range is fairly common

Marcos: i'd like to see more examples in the spec

heycam: i try to include one example per construct

Marcos: i'm doing a review of it

anne: are we doing another LC?
... and if we do, could we add String Enumerations
... as a replacement for string constants

heycam: I talked to the WebPerf guys
... and they're happy with dropping that
... wrt LC, do you have to if you make normative changes?

darobin: if you make changes which would invalidate a review, then 
you're supposed to go back to LC
... normally we would have to go to LC, especially if we made this change
... LC isn't a big deal, it's just process
... we can have a 3 week last call, and if everyone is happy, just move 
to CR
... and start testing
... does anyone want to be the testing chief for webidl?

heycam: i thought that was only for new specs

Marcos: HTML5 tests most of it, right?

jrossi2: that's irrelevant, we need an example of each thing

<anne> heycam, what about AllowAny?

<anne> heycam, I guess you have that recorded somewhere...

Josh_Soref: can't we just create a table for each feature of WebIDL and 
an interface in a given spec for it

Travis_MSFT: i think we solve the Example requirement and Testsuite by 
correlating to Spec items

<scribe> ACTION: Travis_MSFT to lead testing coordination for WebIDL 
[recorded in http://www.w3.org/2011/11/01-webapps-minutes.html#action02]

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

<MikeSmith> trackbot, status?

<scribe> ACTION: Travis to lead testing coordination for WebIDL 
[recorded in http://www.w3.org/2011/11/01-webapps-minutes.html#action03]

<trackbot> Created ACTION-638 - Lead testing coordination for WebIDL [on 
Travis Leithead - due 2011-11-09].

heycam: AllowAny is in the list of things from the LC feedback

<MikeSmith> action-638?

<trackbot> ACTION-638 -- Travis Leithead to lead testing coordination 
for WebIDL -- due 2011-11-09 -- OPEN

<trackbot> http://www.w3.org/2008/webapps/track/actions/638

heycam: it had implications relating to override

anne: I wasn't clear where it was used, apart from XHR

[ heycam talks about overloads ]

[ specifically String and Number versions with AllowAny ]

ACTION darobin to ACTION rafaelw (or the Google AC) to send how to 
handle single pass not emptying all mutation queues to the list

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

ACTION boarlicker to ACTION rafaelw (or the Google AC) to send how to 
handle single pass not emptying all mutation queues to the list

<trackbot> Created ACTION-639 - ACTION rafaelw (or the Google AC) to 
send how to handle single pass not emptying all mutation queues to the 
list [on Robin Berjon - due 2011-11-09].

darobin: any other issues?

<Ms2ger> Agenda: 
http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Tuesday.2C_November_1
Summary of Action Items
[NEW] ACTION: Art and Charles to make a proposal about how to appoint a 
person to be assigned for testing for a spec. [recorded in 
http://www.w3.org/2011/11/01-webapps-minutes.html#action01]
[NEW] ACTION: Travis to lead testing coordination for WebIDL [recorded 
in http://www.w3.org/2011/11/01-webapps-minutes.html#action03]
[NEW] ACTION: Travis_MSFT to lead testing coordination for WebIDL 
[recorded in http://www.w3.org/2011/11/01-webapps-minutes.html#action02]

[End of minutes]

Received on Wednesday, 2 November 2011 21:12:59 UTC