See also: IRC log
DKA: JT, all ready for us?
JT: Yes, room booked, local arrangements page up and sent out
JT: Go out for lunch, or have things laid on?
<slightlyoff> I'd be happy to go out
<slightlyoff> I feel like arranging lunch has been a burden for organizers so far
TBL: Two catered in, one out
JT: Will do
... Light breakfast too?
DKA: Yes, please
... Developer meet-up -- looking for venue
... Hoping to get Google campus, not confirmed
... Fallback is GSMA
... This is all for evening of the 7th
... I'll put this up on Eventbrite
... Dinner out on evening of the 8th
<dka> http://www.w3.org/wiki/TAG/Planning/2014-01-F2F
<slightlyoff> oh good
<slightlyoff> can we schedule time to discuss the layering of Web Components at the F2F?
DKA: Invited Dominique Hazaël-Massieux to join us to talk about "permissions" topic that he would like TAG input on.
<slightlyoff> I think it'd be an important thing to review
DKA: Hoping to invite Phil Archer to pick up on the Data activity
<slightlyoff> sure
<slightlyoff> also, the JSON thing
<slightlyoff> it's coming! really!
<timbl> :)
<slightlyoff> do we want to talk about the JSON thing today?
<slightlyoff> hrm...
DKA: Yes, good, we'll put the Web Components topic on
<slightlyoff> do we want to put any of the HTTP2 stuff on the agenda? is there anything new there?
<JeniT> add capability URLs to agenda
TBL: Timing for each day?
DKA: 0830 for 0900 start
... End at 1730
DKA: Still looking for a venue --
date is fixed for 4 April
... Downtown, or OK further afield
... Suggestions welcome
<slightlyoff> Google is hard...but I can look
DKA: Push API, Web Animations, Web Crypto
<slightlyoff> I'm prepared to talk about push API
<slightlyoff> ah, yes
<slightlyoff> https://dvcs.w3.org/hg/push/raw-file/tip/index.html
AR: Push API has some good parts and
some less good parts
... I'm not happy with the layering aspects
<slightlyoff> https://dvcs.w3.org/hg/push/raw-file/tip/index.html#navigator-interface
AR: Current spec says Navigator gets a Manager attached to it
function registerPush() { navigator.push.register().then( function(value) { pushRegistrations.push(value); registerWithAppServer(value); }, function(reason) {alert("darn! "+ reason );} ); }
AR: Good promise-based
registration
... Why is this different from [??]
... Why register for multiple servers?
if (navigator.hasPendingMessages("push")) { // do any special pre-processing before push messages are delivered } last_version = null; // initialize last message version navigator.setMessageHandler("push", gotPush); navigator.setMessageHandler("push-register", reRegisterPush);
AR: worst part of API is this.
... setmessagehandler seems to suggest you'll be pushing a
javascript message without a specific context.
... who wants this - in a world where if you close the tab you
can't get push messages. Or is the idea that when the tab is
reawakened you now get the push messages? And if so why are these
not events just sent to the document?
... The use case isn't particularly clear.
AR: These should just be events,
instead of messages
... I think a good chunk of this needs to be events-based, rather
than message delivery
SK: I agree, I had the same difficulty figuring out the context/background assumptions
SK: I think it's premature to send a review until these things are clear
<dka> Suggest a way forward here: Alex can you capture your thoughts into the document, then send them over to the working group chairs and spec editors...
<slightlyoff> I like this plan
DKA: So we need to fold what AR said into SK's document ASAP, then send some kind of notification of our higher-level concerns (as opposed to a detailed review) to the WG, and ask them to join us on a call soon.
<slightlyoff> +1
AR: Right, the document as it stands is not ready for an implementer to read.
DKA: We do have one call scheduled before the end of the year
<slightlyoff> happy to draft something that that repo today to outline areas for discussion
DKA: I will try to line them up for 19 December if we can move that fast
<ht> +1
<dka> +1
<slightlyoff> SGTM, I can be there on the 19th
SK: +1
<plinss> +1
<slightlyoff> yep, will do
DKA: First step is to get AR's comments into the feedback document
<slightlyoff> apologies for having delayed this discussion until this week
DKA: Let me know when that's done, and then I'll get in touch with the editors
SK: Comments, anyone?
AR: Where are they in the Process? Are they at Last Call?
PL: Still [an ordinary] WD
<slightlyoff> http://dev.w3.org/fxtf/web-animations/
<Yves> still regular WD, not even LC
DKA: SK has raised some issues in his
review [see above]
... Mostly not major, but levels of abstraction could be
SK: I didn't find any major issues, I
thought the spec was very good
... There are related contentious issues, and some weird behaviours
are suggested
<slightlyoff> there are some real naming issues (the shed should be green!): "SeqGroup", "ParGroup", etc.
SK: It's a very complicated spec, we really need another reviewer
DKA: Can someone volunteer to spend the time
<slightlyoff> I should...I've been asked to look at it from the Google side as well
PL: I already volunteered, will do as soon as I can
<slightlyoff> at least everything has constructors = )
DKA: It would be good to finish this off by the F2F
<slightlyoff> most of the Google folks are in Sydney
DKA: And maybe have a live feedback session via IRC/Voice/...
<slightlyoff> Tab's usually PST
PL: Coming from the FX task force (CSS and SVG), mostly SVG input latterly
... Timezones not v. friendly
<dka> https://github.com/w3ctag/spec-reviews/blob/master/2013/11/WebCrypto.md
<slightlyoff> my apologies that I haen't finished something coherent for crypto
DKA: AR, ready to talk about this
yet?
... There's been a lot of work going on
AR: Group has a lot of
challenges
... Particularly wrt scope
... Hard to manage many use-cases driving into every
discussion
... Trying to decide about low- vs. high-level API
... Currently aiming for low-level
... Looking at streams vs. promises, worried about churn in the
promises spec
... Question about including algorithms into discussion of
APIs/implementations
... I'm not too worried about the overall API
... I think we may need to get involved wrt layering
... So consider secure vs. insecure keys
... There's a use-case challenge there which hasn't been fully
recognized
... How can you talk about embedding MD5 in Javascript, when
Javascript strings aren't byte arrays, for example, of
layering.
<dka> Does it make sense to schedule some f2f time in London on this with the wg chair Virginie?
TBL: A well-defined coercion from string to bytes, would that help?
AR: Absolutely -- TAG could usefully push for this
TBL: From Crypto to TC39?
AR: Probably better from the TAG
<slightlyoff> +1
DKA: Virginie, WG Chair of Crypto, is
in France, perhaps could come to F2F to talk about this, and on
Security on the Web topic
... Other topics?
DKA: Heads up wrt IETF in London, with STRINT workshop ahead
<timbl> IETF is March 2-7, 2014
<dka> https://www.w3.org/2014/strint/
DKA: Strengthening the Internet
against Prevasive Monitoring
... Feeds into HTTP-2 discussion of TLS
... Adjourned