IRC log of tagmem on 2013-05-29
Timestamps are in UTC.
- 08:11:14 [RRSAgent]
- RRSAgent has joined #tagmem
- 08:11:14 [RRSAgent]
- logging to http://www.w3.org/2013/05/29-tagmem-irc
- 08:11:16 [trackbot]
- RRSAgent, make logs public
- 08:11:16 [Zakim]
- Zakim has joined #tagmem
- 08:11:18 [trackbot]
- Zakim, this will be TAG
- 08:11:18 [Zakim]
- I do not see a conference matching that name scheduled within the next hour, trackbot
- 08:11:19 [trackbot]
- Meeting: Technical Architecture Group Teleconference
- 08:11:19 [trackbot]
- Date: 29 May 2013
- 08:11:44 [ht]
- ScribeNick: ht
- 08:11:50 [JeniT]
- JeniT has joined #tagmem
- 08:11:52 [ht]
- Scribe: Henry S. Thompson
- 08:12:36 [marcosc]
- marcosc has joined #tagmem
- 08:12:38 [ht]
- Meeting: TAG Face-to-face, London
- 08:13:20 [ht]
- ht has changed the topic to: Agenda: http://www.w3.org/2001/tag/2013/05/29-agenda.html
- 08:13:37 [timbl]
- timbl has joined #tagmem
- 08:15:45 [ht]
- Chairs: Noah Mendelsohn, Peter Linss, Dan Appelquist
- 08:15:53 [noah]
- noah has joined #tagmem
- 08:16:49 [noah]
- The it's not an agenda: http://www.w3.org/2001/tag/2013/05/29-agenda.html
- 08:17:08 [noah]
- The agenda wiki: http://www.w3.org/wiki/TAG/Planning/May-2013-F2F
- 08:17:31 [ht]
- Topic: Intro
- 08:17:43 [ht]
- NM: I had a meeting with PL and DA last night
- 08:18:03 [ht]
- ... Our goal is to generate momentum, and get some major topics moving
- 08:18:15 [ht]
- ... In principle I'm still chair, for a few days
- 08:18:25 [noah]
- http://www.w3.org/2001/tag/2013/04/18-minutes
- 08:18:25 [ht]
- ... In practice PL and DA will be running things
- 08:18:42 [noah]
- http://www.w3.org/2001/tag/2013/05/16-minutes
- 08:19:02 [ht]
- RESOLUTION: http://www.w3.org/2001/tag/2013/04/18-minutes are approved as a correct record of our meeting of 2013-04-18
- 08:19:04 [noah]
- http://www.w3.org/2001/tag/2013/05/29-agenda.html
- 08:19:35 [ht]
- RESOLUTION: http://www.w3.org/2001/tag/2013/05/16-minutes are approved as a correct record of our meeting of 2013-05-16
- 08:20:42 [ht]
- NM: We have both the historic 'agenda' page http://www.w3.org/2001/tag/2013/05/29-agenda.html and the Wiki http://www.w3.org/wiki/TAG/Planning/May-2013-F2F -- we'll sort out what we edit as we go along
- 08:21:44 [ht]
- NM: I'm very grateful to TBL for giving me the opportunity to serve as chair for the last 4 years, and a member before that, but I'm also confident that this is a good time to hand over
- 08:22:50 [ht]
- DA: [recites the declaration of independence]
- 08:23:12 [ht]
- s/DA: [recites the declaration of independence]//
- 08:23:47 [ht]
- DA: The TAG is changing now, reflecting a change in the Web community
- 08:24:13 [ht]
- ... More of a leadership role is being called for, not exclusively, but an essential part of the conversation
- 08:24:29 [ht]
- DA: The new membership of the TAG is part of that
- 08:25:31 [ht]
- DA: Our challenge is to take this injection of energy and use it to generate momentum around the topics we choose to take forward
- 08:25:57 [ht]
- ... We need to use the next 3 days to propel us
- 08:26:32 [ht]
- PL: I'd like to identify some short-term demonstrable impact
- 08:27:48 [ht]
- YK: Myself, AR and AvK have been getting used to how the TAG works, and I think we're ready now to start getting work done
- 08:28:14 [ht]
- DA: So, next step is to work on the Agenda, via the wiki
- 08:29:06 [ht]
- HST: Logistics?
- 08:29:41 [ht]
- AvK: Lunch is sometime between 12 and 1...
- 08:30:27 [ht]
- DA: Thursday evening at 1830 we have 60 web devs coming to give us their . . . input
- 08:31:54 [ht]
- NM: Structure?
- 08:32:14 [ht]
- DA: It's a reception, start by introducing ourselves, then mingle
- 08:32:26 [ht]
- AvK: We should have an intro about what we do
- 08:32:42 [ht]
- DA: Yes, but the point is not for us to talk to them, but for us to _listen_ to them
- 08:32:51 [ht]
- s/to them/at them/
- 08:33:03 [ht]
- DA: At 2100 we dinner nearby
- 08:33:29 [ht]
- s/dinner/have dinner/
- 08:34:22 [ht]
- DA: On Friday, we'll aim to wrap by 1600
- 08:34:56 [ht]
- Topic: Agenda
- 08:35:15 [ht]
- NM: We do need some time to discuss next (2?) f2f dates/locations
- 08:35:23 [ht]
- ... 1st afternoon is often good for that
- 08:35:30 [ht]
- NM: We have maybe 1 in October
- 08:35:39 [ht]
- ... and nothing after that
- 08:37:33 [ht]
- YK: We should put meta-topics early, so we don't keep circling back to them
- 08:37:40 [ht]
- ... AR and I have some suggestions
- 08:38:13 [ht]
- TBL: I sent some suggestions
- 08:39:09 [ht]
- s/suggestions/suggestions about Futures/
- 08:39:25 [Yves_]
- Yves_ has joined #tagmem
- 08:39:45 [ht]
- YK: Yes, and we should discuss that topic -- my suggestion was to get the strategic discussion at least started first
- 08:39:59 [ht]
- [wiki -> whiteboard agenda negotiation]
- 08:46:17 [ht]
- NM: Responsive?
- 08:46:33 [ht]
- DA: Responsive _design_
- 08:47:34 [ht]
- YK: E.g. reacting to orientation change of the client device
- 08:48:02 [ht]
- DA: Goals and TAG operations are not the same
- 08:56:24 [darobin]
- darobin has joined #tagmem
- 09:06:18 [ht]
- DA: Whiteboard is a tentative plan for the Agenda
- 09:06:27 [ht]
- [will be captured and posted]
- 09:06:32 [ht]
- Topic: Goals of the TAG
- 09:06:55 [dka_]
- dka_ has joined #tagmem
- 09:07:02 [ht]
- YK: We've cleared our plate a bit over the last few months, which is good
- 09:07:23 [ht]
- ... New members were asked to wait a bit before driving forward, and we've done this
- 09:07:44 [ht]
- YK: We'd like to broaden 'architecture' to include the architecture of the platform
- 09:07:53 [dka_]
- q?
- 09:08:16 [ht]
- ... We'd like the TAG to take this on: help WGs coalesce around a coherent approach to APIs
- 09:08:32 [ht]
- ... Help them to coordinate
- 09:09:28 [ht]
- YK: This means asking WGs to present new stuff to us, and move the TAG to the forefront of managing the overall architecture of the platform
- 09:09:38 [ht]
- s/asking/encouraging/
- 09:09:54 [ht]
- MC: We can't and shouldn't compel WGs
- 09:10:12 [ht]
- YK: Indeed, but it is our job to seek coherence
- 09:10:39 [ht]
- NM: That's what we're chartered to do, but we have no enforcement powers, and it doesn't always worked
- 09:10:53 [ht]
- s/doesn't/hasn't/
- 09:11:09 [ht]
- YK: Past failures, yes, but let's look to the future
- 09:11:21 [ht]
- NM: It extends back past HTML5. . .
- 09:11:40 [ht]
- AR: I've spending a lot of time on this (API coherence) in my day job
- 09:11:56 [wycats_]
- q+ to discuss the related TC39 process
- 09:11:57 [ht]
- ... There's a real need, on the part of people putting individual specs forward
- 09:12:59 [ht]
- AR: They're not looking for an "us vs. them" confrontation, so if we come with the right kind of helpful suggestions, we can earn a responsive hearing
- 09:13:17 [wycats_]
- I don't think we can do this on an as-noticed basis
- 09:13:47 [wycats_]
- we need to take on the responsibility of being aware of the platform's progress and proactively discovering overlapping and conflicting architectures
- 09:13:57 [ht]
- AR: Examples: Web Midi, Web Crypto, Web RTC -- all of these have defined separate but incompatible callback styles
- 09:14:09 [ht]
- TBL: Patterns the same?
- 09:14:31 [ht]
- AvK: Similar problems, but arbitrary design differences in response
- 09:14:48 [ht]
- AvK: Local perspective doesn't motivate generic solutions
- 09:15:05 [ht]
- TBL: Not just a matter of renaming/reordering parameters
- 09:15:13 [ht]
- AR: No, subtle semantic differences
- 09:15:32 [ht]
- AvK: Inventing new primitives independently
- 09:15:46 [ht]
- ... We now have Futures, but a bit too late
- 09:16:00 [ht]
- TBL: Doesn't this require lots of backwards changes?
- 09:16:36 [ht]
- YK: In many cases the changes are pretty easy: replace "return void" as last arg't to "return [future]"
- 09:16:52 [ht]
- AR: And backporting gives WGs something to do
- 09:16:55 [ht]
- TBL: Cost?
- 09:17:07 [ht]
- AR: GC -- Futures take storage from the heap
- 09:17:37 [ht]
- DA: Up-level: We have the opportunity to influence other groups, from a position of "we're here to help"
- 09:18:07 [dka_]
- q?
- 09:18:09 [ht]
- DA: We need to map out which groups/individuals will be most receptive, so we can quickly demonstrate TAG value
- 09:18:09 [noah]
- q+ timbl
- 09:18:50 [wycats_]
- DA: Agreed. We already have a level of success, but the TAG is not getting credit. By taking on the responsibility explicitly, we can associate the wins with TAG
- 09:18:53 [wycats_]
- (things like futures)
- 09:19:06 [ht]
- AR: I've seen different levels of cooperativeness -- I meet different levels of engagement with the proposition "We all have responsibility for the commons", but I haven't failed yet
- 09:19:53 [wycats_]
- "structured engagement" -> I like that term
- 09:19:59 [ht]
- AR: We're hoping for a substantially changed new version of IndexDB, for instance
- 09:20:28 [ht]
- AR: By and large people are trying to do the right thing, we need to make it easier for them
- 09:20:35 [timbl]
- q?
- 09:21:34 [ht]
- DA: The social construct of 'the commons' is a very valuable hook to hang this all on. Also, the idea of involving TAG work with our day jobs is an important one to keep our eyes on
- 09:22:08 [ht]
- AR: Specific issues: Futures/Promises; Streams (we _need_ this, it's a trainwreck at the moment)
- 09:22:41 [ht]
- AR: We need a process for Streams in the same way we got Futures done
- 09:22:50 [ht]
- TBL: Futures are done?
- 09:22:59 [ht]
- AR: Short answer: yes
- 09:23:10 [ht]
- YK: TC39 is more-or-less agreed
- 09:23:19 [ht]
- TBL: Unresolved issues?
- 09:23:31 [ht]
- AvK: There were, but they have been resolved
- 09:23:47 [ht]
- TBL: Microsoft happy?
- 09:23:58 [ht]
- YK: Their rep. has signed off, yes
- 09:24:07 [ht]
- ack wycats_
- 09:24:07 [Zakim]
- wycats_, you wanted to discuss the related TC39 process
- 09:24:28 [ht]
- YK: My perspective is informed by my TC39 experience
- 09:24:44 [ht]
- ... They don't meet all that often, they can't _do_ the technical work
- 09:24:58 [ht]
- ... They manage the 'complexity budget' of the language
- 09:25:27 [ht]
- ... And focussing on that is what TC39 does best, leaving the detailed technical work to small groups
- 09:25:40 [ht]
- YK: And that's v. parallel to the TAG situation
- 09:25:50 [ht]
- TBL: Yes, that's what we're chartered to do
- 09:26:34 [ht]
- YK: So "come to us", not for approval, but because we have something recognizable to offer them: our higher-level perspective on the platform
- 09:27:00 [ht]
- YK: "You (or any WG) are welcome to come and present for 30 minutes, and we'll try to help"
- 09:28:25 [ht]
- TBL: So, analogous to TC39, make sure that everybody understands the direction e.g. Futures are going, so that WGs are not tempted to say "They're behind us, we can't wait" -- in our role as glue, the TAG can re-assure people that they can and should switch
- 09:28:52 [ht]
- ... Even giving tutorials at TPAC...
- 09:29:04 [dka_]
- q?
- 09:29:35 [ht]
- q- timbl
- 09:30:13 [ht]
- AR: We need some kind of calendar or temperature chart, so we know what's nearing the point where we need to get involved
- 09:30:32 [ht]
- DA: We can't change the W3C process on our own
- 09:31:04 [ht]
- JT: Being more aware of what W3C as a whole is working on, and the state of the various WGs
- 09:31:34 [Yves]
- http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications
- 09:31:38 [ht]
- YK: You can see all the drafts, and sort by status, on the TR page
- 09:31:53 [ht]
- ... it's hard to use, but it's all there
- 09:32:29 [ht]
- YL: WebApps dashboard is a possible model: http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications
- 09:33:00 [ht]
- NM: Sometimes that's too late -- charter proposals are sometimes the point you need to catch: see e.g. SOAP
- 09:34:16 [timbl]
- https://www.ietf.org/mailman/listinfo/new-work
- 09:34:19 [ht]
- YK: Standing agenda item for New Charters
- 09:34:23 [annevk]
- wycats_: raw data is http://www.w3.org/2002/01/tr-automation/tr.rdf I think
- 09:34:32 [annevk]
- wycats_: maybe http://www.w3.org/TR/tr.xml
- 09:35:03 [ht]
- HST: It's an 80/20 thing, we can do better than we are doing now, without assuming we will get everything
- 09:35:44 [timbl]
- ooops new-work is not public
- 09:36:19 [ht]
- DA: YL, can you help populate that agenda item?
- 09:36:44 [ht]
- YL: Can do: I'll take a standing action item:
- 09:37:44 [ht]
- ACTION Yves to bring new W3C initiatives to TAG's attention, open-ended, due 2015-12-31
- 09:37:44 [trackbot]
- Created ACTION-802 - Bring new W3C initiatives to TAG's attention, open-ended, due 2015-12-31 [on Yves Lafon - due 2013-06-05].
- 09:38:07 [ht]
- NM: Anyone attending IETF regularly
- 09:38:29 [ht]
- s/Anyone/Need this beyond W3C. Anyone/
- 09:38:41 [ht]
- JT: Larry Masinter was, no-one now
- 09:39:31 [ht]
- DA: Other opportunities for quick engagement: Web midi, Web RTC, Sysapps, Webapps
- 09:39:35 [ht]
- DA: Webapps is big
- 09:39:42 [ht]
- YK: Let _them_ roll it up
- 09:40:30 [ht]
- ACTION Dan to talk with Art Barstow and/or Charles Mac??-Neville to find out who from Webapps might come to talk to us
- 09:40:30 [trackbot]
- Created ACTION-803 - Talk with Art Barstow and/or Charles Mac??-Neville to find out who from Webapps might come to talk to us [on Daniel Appelquist - due 2013-06-05].
- 09:40:59 [ht]
- MC: I will present for Sysapps
- 09:41:18 [ht]
- MC: I could use the Sysapps slot
- 09:41:42 [ht]
- NM: Do this kind of thing at TPAC, with the _whole_ WG?
- 09:41:50 [timbl]
- wycats_, FTR the TR page data is in http://www.w3.org/2002/01/tr-automation/tr.rdf
- 09:41:53 [ht]
- HST: That's the _second_ step, surely
- 09:42:20 [ht]
- NM: That has often done a lot to build bridges -- get recognition of who we are and what we can do
- 09:42:36 [wycats_]
- http://www.w3.org/TR/tr.xml seems to return something
- 09:42:55 [ht]
- DA: We should indeed discuss what we do at TPAC, in general
- 09:43:13 [ht]
- ... Two TPACs a year?
- 09:43:56 [ht]
- TBL: IETF meet 3 times a year
- 09:44:11 [ht]
- DA: Web audio?
- 09:44:57 [ht]
- MC: I can reach out to them, but they are pretty resistent to change
- 09:45:09 [ht]
- YL: The editor is in London. . .
- 09:45:38 [ht]
- AR: It has a strong core functionality, but the API has some idiosyncratic properties
- 09:46:05 [ht]
- DA: Invite the chair for Friday?
- 09:46:26 [ht]
- AR: Great topic for telcon
- 09:47:06 [ht]
- ACTION Yves to invite Olivier Theroux to lunch on Friday due 2013-05-29
- 09:47:06 [trackbot]
- Created ACTION-804 - Invite Olivier Theroux to lunch on Friday due 2013-05-29 [on Yves Lafon - due 2013-06-05].
- 09:47:25 [ht]
- trackbot, action 804 due 2013-05-30
- 09:47:32 [ht]
- trackbot, action-804 due 2013-05-30
- 09:47:32 [trackbot]
- Set ACTION-804 Invite Olivier Theroux to lunch on Friday due 2013-05-29 due date to 2013-05-30.
- 09:48:01 [noah]
- ACTION-804?
- 09:48:02 [trackbot]
- ACTION-804 -- Yves Lafon to invite Olivier Theroux to lunch on Friday due 2013-05-29 -- due 2013-05-30 -- OPEN
- 09:48:02 [trackbot]
- http://www.w3.org/2001/tag/group/track/actions/804
- 09:48:08 [ht]
- ACTION Anne to find a representative of Web RTC to talk to the TAG
- 09:48:08 [trackbot]
- Created ACTION-805 - Find a representative of Web RTC to talk to the TAG [on Anne van Kesteren - due 2013-06-05].
- 09:48:54 [ht]
- YK: I'll undertake to keep TC39 information flowing to the TAG
- 09:49:43 [ht]
- JT: There is new work on SemWeb tabular data on the web, next step is CSV, Phil Archer and Ivan Herman are involved
- 09:50:13 [ht]
- ACTION Jeni to invite Phil Archer to talk to the TAG
- 09:50:13 [trackbot]
- Created ACTION-806 - Invite Phil Archer to talk to the TAG [on Jeni Tennison - due 2013-06-05].
- 09:51:02 [ht]
- HST: That list is long enough -- if we want to have early impact, we will need to narrow that down as soon as we've had a few presentations/visitors
- 09:51:47 [JeniT]
- wycats_: uriburner is broken I guess
- 09:51:47 [ht]
- ACTION Dan to invite someone from Responsive Images CG to talk to the TAG
- 09:51:47 [trackbot]
- Created ACTION-807 - Invite someone from Responsive Images CG to talk to the TAG [on Daniel Appelquist - due 2013-06-05].
- 09:52:25 [ht]
- YK: Should we look at the general issue of relations with CGs?
- 09:53:08 [ht]
- DA: They are so diverse. . .I don't think a blanket approach is possible
- 10:17:15 [dka_]
- dka_ has joined #tagmem
- 10:18:09 [dka_]
- q?
- 10:18:54 [ht]
- MC: What are the concrete action items?
- 10:19:11 [ht]
- HST: Actions for contacts to WGs are in the tracker
- 10:19:27 [ht]
- YK: I think we're good for now
- 10:19:46 [ht]
- DA: I'm satisfied for now -- we need to get to having concrete progress
- 10:20:56 [ht]
- JT: So we have a plan for getting information, and then maybe we feed back into those WGs, maybe by email. But what about any deliverables? Are we still looking to write anything?
- 10:21:27 [ht]
- YK: We've talked about an API Design Guide
- 10:21:43 [ht]
- AR: Futures could be a deliverable
- 10:22:01 [ht]
- DA: Would we write something which points to other docs, saying: use this?
- 10:22:50 [ht]
- AR: More general: What does it mean to design a good Web API: declarative, structured, etc.
- 10:23:11 [ht]
- ... Sort of a "So you're building your first API -- here's what you need to know"
- 10:23:43 [ht]
- YK: Separate legacy from new stuff, so that legacy doesn't get copied on
- 10:24:22 [ht]
- AR: New specs keep getting written which indiscrimately use too much of WebIDL
- 10:24:40 [ht]
- YK: We need "WebIDL, the good bits"
- 10:24:49 [ht]
- TBL: E.g.?
- 10:25:34 [ht]
- AR: Objects [?] w/o constructors, overloaded methods based on type alone, not arity
- 10:25:51 [ht]
- TBL: Doesn't JQuery handle all that
- 10:26:00 [ht]
- YK: Yes, but at huge cost in some cases
- 10:26:50 [ht]
- MC: A lot of the problems stem from people copying existing WebIDL w/o understanding it
- 10:27:52 [ht]
- AR: It's not that the IDL is necessarily weird, it's the relationship _between_ WebIDL and JS which leads to great weirdness
- 10:28:05 [ht]
- TBL: So in principle it would be good to design just for JS. . .
- 10:29:07 [ht]
- MC: It leads to one VM inside another, with JS at both ends, which is just . . . confusing
- 10:30:34 [ht]
- MC: Any reason why we _shouldn't_ do a Futures API spec?
- 10:31:06 [ht]
- HST: It's unprecedented. YK's TC39 model also doesn't suggest that, rather that we need to motivate a WG to do it.
- 10:31:33 [ht]
- MC: But there isn't a WG for shared APIs which many groups need
- 10:31:50 [ht]
- AR: We may need to embed someone in an existing WG
- 10:32:18 [ht]
- DA: We clearly need to identify work items which don't have a home
- 10:33:04 [ht]
- ... Then we might e.g. send a message to ac-forum to the effect "The TAG thinks this item needs a home, what shall we do"
- 10:33:40 [ht]
- MC: Still we need some stub, say for Navigation Control, where the TAG says: here's a draft requirement, this needs to be taken forward
- 10:35:20 [ht]
- trackbot, close ACTION-804
- 10:35:20 [trackbot]
- Closed ACTION-804 Invite Olivier Theroux to lunch on Friday due 2013-05-29.
- 10:35:56 [ht]
- DA: So should Promises by a finding?
- 10:36:31 [ht]
- AR: I'm more interested in the overall API Best Practices document, where using Promises would play a part
- 10:36:51 [ht]
- JT: Is it spec. authors we're aiming at, or web devs?
- 10:37:18 [ht]
- AR: W3C has little ability to affect web devs, except via specs, so, spec. authors
- 10:37:48 [ht]
- NM: This is a good example of why 'architecture' is valuable to keep in view
- 10:39:11 [ht]
- ... So either or both communities, but the point we want to push is "there is a benefit/set of trade-offs wrt using composable APIs, and here's how using Promises fits with that"
- 10:39:28 [ht]
- YK: Not at too high a level
- 10:39:52 [ht]
- NM: So, no "On Promises" document?
- 10:40:18 [ht]
- YK: Yes, but with emphasis on concrete Best Practices, not so much on _why_ they are Best
- 10:40:50 [ht]
- YK: So that's a separate Note on why you should use Promises
- 10:41:09 [ht]
- ... but not with a cookbook
- 10:42:04 [ht]
- AR: I will undertake to produce that Note
- 10:42:25 [wycats_]
- it makes sense for the best practices docs to link to the architecture notes
- 10:42:43 [ht]
- YK: I expect the Good Practices document will often come first, with the architecture 'why' note later
- 10:43:45 [ht]
- JT: Still not sure about the targetting
- 10:43:59 [ht]
- HST: Both those docs are targetted. . .
- 10:44:08 [ht]
- YK: . . . at spec authors
- 10:44:33 [ht]
- AvK: At least some devs want to understand 'why' as well
- 10:45:31 [ht]
- PL: The guide to WebApps architecture Best Practices is really needed
- 10:45:49 [ht]
- AR: What did HTML do right, and what did they do wrong
- 10:46:06 [ht]
- ... e.g. don't loose sight of the tree structure
- 10:47:05 [ht]
- YK: If we write such a guide, it would be obsolete in a year
- 10:47:25 [noah]
- With apologies for the residual use of CVS, I have posted a (slightly fuzzy) image of the agenda whiteboard as of approximately 11:30 AM Wed.
- 10:47:27 [noah]
- It
- 10:47:30 [noah]
- It's at http://www.w3.org/2001/tag/2013/05/WhiteboardAgenda1130Wed.jpg
- 10:48:12 [ht]
- HST: Now talking about a Primer?
- 10:48:23 [ht]
- YK: Not us, rather they exist already
- 10:50:08 [ht]
- HST: So the "Guide to WebApps Best Practices" and the "API Best Practices" mentioned above are two distinct documents
- 10:50:38 [ht]
- HST: The API Best Practices is aimed at spec. writes, and we are all pretty much clear it should happen
- 10:51:45 [ht]
- DA: The "Guide to WebApps architectural principles" is for those who want to know why
- 10:52:06 [ht]
- s/WebApps Best Practices/WebApps archictural principles/
- 10:54:53 [ht]
- PL: Two docs, two targets, both docs need both a how and a why, so the main difference is between the audiences: the "API Design Best Practices" is for spec. writers, the "Guide to WebApps architectural principles" is for devs
- 10:55:37 [ht]
- PL: Two document _spaces_
- 10:56:07 [ht]
- NM: The architectural principles doc is for both communities
- 10:56:25 [ht]
- s/API Best Practices/API Design Best Practices/
- 10:56:56 [ht]
- DA: When we had the #URI discussion, JT produced a great blog post, which evolved and morphed into a finding
- 10:57:25 [ht]
- DA: We could take AR's blog post on Web Components down a similar route
- 10:57:50 [ht]
- NM: First WD is a good route too
- 10:58:17 [ht]
- PL: Lets get back from mechanism to substance
- 10:59:18 [ht]
- YK: The key point is to back up design choices which depend on architectural goals with documents which articulate the architectural background
- 10:59:30 [ht]
- Topic: TC39
- 10:59:38 [dka_]
- dka_ has joined #tagmem
- 10:59:52 [noah]
- What I was specifically suggesting was: if you think Alex's blog post is a good start, you could start by cloning at is a TAG blog post to get it in W3C space, or use it as the starting point for a first draft. The advantage of the latter is much more visibility, and the probability that there will be undated as well as dated URIs the people can use to watch the ideas evolve.
- 11:00:01 [ht]
- YK: We all talked about TC39 in our platform when we ran for the TAG
- 11:00:16 [ht]
- ... W3C and TC39 complain about each other
- 11:00:20 [slightlyoff]
- noah: and I'm totally good with that. But that stuff probably needs heavy editing = )
- 11:00:34 [slightlyoff]
- noah: my writing isn't...erm...good
- 11:00:57 [ht]
- YK: TC39 operates almost as if it were a W3C WG, with responsibility for Javascript
- 11:01:24 [ht]
- ... So AR and I have been trying to facilitate coordination as if that were true
- 11:02:04 [ht]
- AR: TC39 don't understand W3C process, many of them come from the Programming Languages community, which doesn't have a precedent for understanding W3C
- 11:02:21 [ht]
- ... They don't yet feel included
- 11:02:28 [noah]
- Alex, while you were out of the room it was Dan A who suggested stealing your blog entry and putting in the TAG block. I was saying: "yes to stealing it", if you're willing, but "suspicious that TAG blog may not be best W3C form in which to put it in"
- 11:05:53 [ht]
- AR: TC39 is evolving---it has shifted focus from just language fixes to a recognition of its place in devs lives
- 11:06:00 [ht]
- s/devs/devs'/
- 11:06:37 [ht]
- YK: Many new members are designers/devs (as opposed, at least a bit, to Prog Lang people)
- 11:08:14 [ht]
- AR: TC39<->DOM is a particular challenge, in that TC39 feels that the DOM unilaterally create new semantics, whereas the DOM WG feels that TC39 change things that affect the DOM unilaterally
- 11:08:34 [ht]
- NM: So there's a coordinating role that the TAG could/should play?
- 11:08:46 [ht]
- YK: Yes
- 11:08:54 [ht]
- NM: Should we write something?
- 11:09:31 [ht]
- s/Yes/Yes: encourage DOM to recognise that they sit on top of JS, not independent of it/
- 11:09:53 [ht]
- YK: AvK is coming to next TC39 meeting
- 11:11:39 [ht]
- NM: Do we need to prepare the ground by going to the DOM WG sooner rather than later?
- 11:12:15 [ht]
- HST: We do introductions and then get out of the way
- 11:13:40 [ht]
- DA: We could invite a TC39 rep to a TAG call, or organize a workshop
- 11:14:08 [ht]
- NM: You get them together too early, they just resume their ongoing battles
- 11:14:56 [ht]
- DA: So AR and AvK will explore ways of engage with the W3C groups
- 11:15:36 [ht]
- HST: There is no DOM WG, right?
- 11:15:39 [ht]
- AvK: WebApps actually own the DOM now
- 11:16:13 [annevk]
- (Part of the confusion might be that some people refer to DOM as all APIs and some mean DOM as just Nodes and such.)
- 11:16:14 [ht]
- YK: We certainly need to know who the sub-group owner is within WebApps
- 11:17:01 [ht]
- YL: WebApps is a meta-group, the chairs know at any point who is working on what
- 11:17:05 [annevk]
- wycats_: http://www.w3.org/2008/webapps/wiki/PubStatus
- 11:18:17 [ht]
- AvK: For some areas under WebApps, a lot of the work is happening at WhatWG, and then being imported into W3C, which means that the PubStatus page is not the end of the story
- 11:18:44 [darobin]
- darobin has joined #tagmem
- 11:18:57 [ht]
- DA: If technical work is going on on e.g. the DOM, wherever it's going on, and there's a coordination problem with TC39, we (the TAG) should help
- 11:19:22 [ht]
- DA: Who's the guy on the WhatWG side?
- 11:19:26 [ht]
- AvK: Me
- 11:19:34 [ht]
- DA: Who's the guy onn the W3C side?
- 11:19:38 [ht]
- AvK: Not me
- 11:20:56 [ht]
- DA: Should we try to meet w. TC39 at TPAC?
- 11:21:02 [ht]
- AvK: It's in China
- 11:21:18 [ht]
- YK: We can invite them. . .
- 11:21:50 [ht]
- AvK: It didn't work well last time
- 11:23:16 [ht]
- AR: We need to have a very concrete activity plan for them
- 11:25:12 [ht]
- HST: We need to make as good as we can on the "TC39 is effectively a WG" story
- 11:25:45 [ht]
- DA: Right, so ask JJ to invite TC39 as full partipants at TPAC
- 11:26:01 [ht]
- YK: TC39 has 15 active members
- 11:26:24 [ht]
- TBL: We should check for scheduling conflicts, and membership issues
- 11:26:58 [ht]
- ... Don't try to solve the whole thing, get a partial picture and then take it to JJ
- 11:28:01 [ht]
- ACTION Dan to pull together a plan for TC39 participation at TPAC in November in China
- 11:28:01 [trackbot]
- Created ACTION-808 - Pull together a plan for TC39 participation at TPAC in November in China [on Daniel Appelquist - due 2013-06-05].
- 11:28:09 [timbl]
- [2013/5/29 10:07:35] Tim Berners-Lee: http://www.w3.org/2013/11/TPAC/
- 11:28:10 [timbl]
- [2013/5/29 10:07:45] Tim Berners-Lee: SHENZHEN, CHINA 11-15 NOVEMBER 2013
- 11:29:27 [ht]
- [Adjourned for lunch until 1330]
- 11:30:27 [ht]
- Scribe: Marcos Cáceres
- 11:30:38 [ht]
- ScribeNick: marcosc
- 11:43:27 [darobin_]
- darobin_ has joined #tagmem
- 12:20:54 [Zakim]
- Zakim has left #tagmem
- 12:31:24 [JeniT]
- JeniT has joined #tagmem
- 12:31:46 [dka_]
- dka_ has joined #tagmem
- 12:34:19 [noah]
- noah has joined #tagmem
- 12:41:32 [marcosc]
- scribe: Marcos
- 12:41:40 [marcosc]
- scribenick: marcosc
- 12:42:03 [marcosc]
- TOPIC: Layering
- 12:46:06 [marcosc]
- yehuda: it's the meta discussion as to why I ran. I've been writting up a document about this. The way the standards process seems to work is driven by use cases. From this they create an API - it's usually extremely high or low level. It gets implemented - done. But then the use cases come up again, and people point to the API
- 12:47:09 [marcosc]
- yehuda: so, if we look at some thing like appcache [history of app cache and how it was made by the WHATWG and friends].
- 12:48:35 [marcosc]
- slightlyoff: [gives overview of a similar situation in with regards to google gears]. With the lessons of Google gears, appcache was born...
- 12:49:03 [slightlyoff]
- marcosc: well, just saying that Google motivated both the Gears and the AppCache work
- 12:49:32 [slightlyoff]
- marcosc: and Aaron Boodman et. al. were working on other things (notably Chrome) by the time AppCache was being built
- 12:51:10 [marcosc]
- yehuda: so, appcache is "scenario solving" - it introduces new capabilities, but introduces new problems/limitations in the platform. So, then developers tried to use it for offline apps, but it didn't work. So I went to look at the imperative API to try to fix the issues.
- 12:52:01 [bkardell]
- bkardell has joined #tagmem
- 12:52:14 [marcosc]
- dan: as a side bar, Andrew Betts has a lot of feedback with regards to app cache from Financial Times' experience with that appcache.
- 12:54:52 [marcosc]
- yehuda: what I am not suggesting is that you do imperative + declarative side of an API and have them match 1 to 1. What I'm saying is that there should be a lower level API (primitive) from which you build the declarative and imperative from. This can be a win for security as you deal with the security issues at a lower/one level. So, given this, you could build XHR, CSP, etc. anything that uses, for example, the network, you use the lower lev
- 12:54:52 [marcosc]
- el network API (e.g., navigation controller).
- 12:55:50 [marcosc]
- yehuda: So, this way, you can basically use navigation controller to impose various security policies or experiment with different solution that then feedback to the platform.
- 12:55:56 [marcosc]
- noah: is this a plugin?
- 12:56:08 [marcosc]
- yehuda: no, this is not a pluging.
- 12:56:23 [marcosc]
- s/pluging/plugin/
- 12:57:06 [marcosc]
- noah: so, you want to be careful with this. As you are downloading a hook that can reroute network requests.
- 12:59:08 [marcosc]
- alex: so, this is my design - will explain: every page is constructed with a url. Controllers are registered against some part of the URL space (e.g., http://example.com/*). So, when the page is loaded in this URL space, install/use this controller.
- 12:59:46 [marcosc]
- alex: so, this uses a "shared working" (bit of code that is securely shared across documents in the same domain)
- 13:00:25 [marcosc]
- noah: so, how is the security checking done?
- 13:01:23 [marcosc]
- noah: so, that code gets cached, and the whole thing fires itself up and runs.
- 13:01:26 [dka_]
- q?
- 13:01:41 [dka_]
- trackbot, start meeting
- 13:01:43 [trackbot]
- RRSAgent, make logs public
- 13:01:43 [Zakim]
- Zakim has joined #tagmem
- 13:01:45 [trackbot]
- Zakim, this will be TAG
- 13:01:45 [Zakim]
- I do not see a conference matching that name scheduled within the next hour, trackbot
- 13:01:46 [trackbot]
- Meeting: Technical Architecture Group Teleconference
- 13:01:46 [trackbot]
- Date: 29 May 2013
- 13:01:49 [marcosc]
- ht: there is some kind of precedence order here.
- 13:01:56 [dka_]
- q?
- 13:02:03 [marcosc]
- alex: last one wins
- 13:02:42 [marcosc]
- dan: you mentioned this is being implemented? by who?
- 13:03:03 [marcosc]
- alex: a bit of work is being done by network controller. I have a team, we are doing it. \
- 13:04:12 [marcosc]
- yehuda: Let say you have an image tag. Right now, it's opaque how an image ends up on the screen, etc. The overall goal that Alex and I are working on is to expose some of those things imperatively - so that people can fix bug in the platform.
- 13:04:23 [marcosc]
- yehuda: and potentially extend the platform
- 13:04:38 [marcosc]
- yehuda: which can then feedback into the standards process
- 13:05:34 [marcosc]
- noah: the TAG spent a long time looking at distributed extensibility. This seems to go in the opposite direction.
- 13:06:20 [marcosc]
- yehuda: in my view there is a crisis of imperative right now (to extend the platform right now, you need to write a ton of JS code - potentially reimplementing parts of the platform).
- 13:08:14 [marcosc]
- alex: here is real example: currently, Firefox does not support WebM. So there is work that coverts code to asm.js to in order to do fast image conversion.
- 13:08:46 [marcosc]
- hp: the point is that you can write a scoped handler
- 13:08:59 [marcosc]
- s/hp/ht/
- 13:09:52 [marcosc]
- noah: it's scoped to the place where the thing came from. That is, if I got this from website X, and you can scope it to the site (e.g., with processing images).
- 13:10:19 [marcosc]
- yehuda: it's not scary to do that, but it could be scary if people write their own PNG handlers
- 13:10:37 [JeniT]
- q?
- 13:10:43 [JeniT]
- q+ to ask what it is the TAG should do
- 13:10:59 [ht]
- q+ to ask why you're using a new tag
- 13:11:14 [marcosc]
- yehuda: once you these hooks, you can imagine users making their own solutions as showing us (standards people) what they want in the core platform
- 13:11:46 [marcosc]
- plinss: what you are asking from the TAG is to define what these hooks could be.
- 13:12:28 [marcosc]
- noah: if you are using markup for this, you could end up with the custom elements and weird markup.
- 13:14:19 [marcosc]
- yehuda: the intention is that people change their markup once a solution is standardised
- 13:14:48 [marcosc]
- alex: so, to get compat, you might need to use a nesting hack. And that is ok.
- 13:15:50 [marcosc]
- yeahuda: there is still going to hacks to get around platform limitations. But for components that are standardized, then the browser just handles that.
- 13:16:04 [JeniT]
- s/yeahuda/yehuda/
- 13:16:14 [marcosc]
- dan: what about prollyfills? wont the web become of a bunch of polly/prollyfills?
- 13:17:03 [marcosc]
- alex: so, the point of polyfills is to help solve a particular problem or overcome limitations - to give users are feature they don't have.
- 13:18:28 [marcosc]
- yehuda: this removes a centralized bottleneck for getting new stuff on the Web.
- 13:19:42 [marcosc]
- noah: my intuition about this stuff is that the general direction is good. Being able to use the web's existing extensibility hooks (e.g., mime types) would be good.
- 13:20:14 [marcosc]
- noah: I wonder if it would be worth while going through the platform to see where the extensibility points are
- 13:21:46 [marcosc]
- noah: up to now, this has been sold as a way for some part of the web community to experiment.
- 13:22:03 [marcosc]
- yehuda: how do you suggest that someone actually solve this problem?
- 13:22:17 [marcosc]
- annevk: so going into this right now doesn't help.
- 13:23:03 [marcosc]
- annevk: there is a problem with this, if you do a cross domain request, you will get a tainted response - so you won't be able to access the bytes
- 13:23:48 [JeniT]
- sounds to me like that there are two possible types of deliverables for TAG here: 1. guide for spec editors to make sure that they build in extension points and 2. possibly guides for web developers to know when and how to extend and upgrade etc
- 13:23:54 [marcosc]
- noah: as Anne says, no one is using the media types.
- 13:24:51 [marcosc]
- noah: so, if say media types is broken, then we should go and fix the broken underlying specs that mandate them in the platfomr.
- 13:24:58 [marcosc]
- s/platfomr/platform/
- 13:25:36 [marcosc]
- timbl: I would be interested to see if you could move from a system that is not well defined to one that is in a secure manner.
- 13:26:16 [marcosc]
- alex: our security model right now is "same origin". It would be great if it was some other model.
- 13:27:56 [marcosc]
- [fast discussion about different examples/scenarios]
- 13:29:05 [marcosc]
- yehuda: I don't think these extensibility points fix fundamental problems on the web, but it doesn't make it worst [...discussion moved to identity and URIs]
- 13:30:12 [marcosc]
- yehuda: right now, this proposal solves some of the friction in the platform.
- 13:31:04 [marcosc]
- annevk: if you wanted to invent new UI widgets, this allows you to create new things to experiment with.
- 13:31:26 [marcosc]
- dan: what is the overlap between when you would use this VS when you would use shadow dom?
- 13:31:43 [marcosc]
- yehuda: this is a sort of implementation of this proposal
- 13:32:14 [marcosc]
- yehuda: it makes composition harder
- 13:32:55 [marcosc]
- alex: gmail was fighting a losing battle against the depth limit of the dom in FireFox.
- 13:33:38 [marcosc]
- [alex explains what the shadow dom is]
- 13:35:00 [marcosc]
- [yehuda gives a concrete example of how input types work with shadow dom in browsers]
- 13:36:08 [marcosc]
- http://www.w3.org/TR/shadow-dom/
- 13:36:57 [marcosc]
- yehuda: you can view it in Chrome's dev tools
- 13:38:36 [marcosc]
- alex: the shadow dom does not affect the document's dom
- 13:39:30 [marcosc]
- alex: a few of use worked together on the shadow dom model (referring to http://www.w3.org/TR/shadow-dom/)
- 13:41:47 [marcosc]
- yehuda: the point is that we assume that people will want to leave behind their own custom elements instead of using the new standardized ones
- 13:42:04 [JeniT]
- q?
- 13:42:50 [marcosc]
- timbl: it might be good for the TAG to recommend a registry for custom tags
- 13:43:10 [marcosc]
- yehuda: I can see something like Ember doing something like that
- 13:43:39 [marcosc]
- alex: we've learned the hard way about accessibility issues
- 13:44:29 [marcosc]
- alex: because they have to send code down the wire, it means they take a huge performance hits which means they sometimes throw away a bunch of stuff (e.g., accessibility)
- 13:45:47 [marcosc]
- ht: the basic metric for some company is: how many staff am I going to have to hire to support some feature?
- 13:46:22 [JeniT]
- shadow-com spec doesn't say anything about <element>, I guess it's somewhere else
- 13:46:28 [JeniT]
- s/shadow-com/shadow-dom/
- 13:47:31 [JeniT]
- ah https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html
- 13:47:53 [marcosc]
- yehuda: we should allow people to make little registries
- 13:48:04 [annevk]
- JeniT, yes
- 13:48:42 [marcosc]
- noah: there was a time when there were multiple element (image/img), eventually one won
- 13:48:57 [JeniT]
- annevk, I thought I saw a primer once
- 13:49:17 [annevk]
- JeniT, https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
- 13:49:24 [annevk]
- JeniT, I think
- 13:49:31 [marcosc]
- yehuda: polymer, from google, will have a lot of stuff that will be very google specific. So it might be ok for them just to use "google-"
- 13:50:00 [marcosc]
- yehuda: we should consider how to allow people to create things without "-"
- 13:50:12 [JeniT]
- annevk, yes that was it
- 13:50:57 [marcosc]
- annevk: "x-" is for browsers. It's a user agent or server layer instead of the app layer.
- 13:52:09 [marcosc]
- noah: there is a case to be made that pointing to your own implementation changes the game. If timbl then goes an invents his own that uses your "xxx-" tag, then that might not cause an issue. But when people go and search for "xxxx-", then it might be a loss.
- 13:52:25 [marcosc]
- alex: it might be an opportunity
- 13:53:18 [marcosc]
- noah: I don't believe the damage is zero, because there might be a place for globally unique identifiers for these
- 13:53:58 [marcosc]
- timbl: there are two ways this can go: 1. to get stuff into html, 2. it becomes a modular programming system.
- 13:54:44 [Norm]
- Norm has joined #tagmem
- 13:56:25 [marcosc]
- [discussion around dependencies, dll hell vs debian dependencies]
- 13:58:24 [dka_]
- q?
- 13:58:32 [dka_]
- q?
- 13:59:48 [marcosc]
- dan: I'm interested in getting some action items. How do we move forward with all this great stuff?
- 14:00:39 [ht]
- ack next
- 14:00:41 [Zakim]
- JeniT, you wanted to ask what it is the TAG should do
- 14:01:39 [marcosc]
- JeniT: this is all excellent. The thing that stands out is being able to go down to a lower level. Not too different form last F2F. What is it that the TAG should be doing on this?
- 14:03:07 [marcosc]
- JeniT: there are a few deliverables: 1. if we are going to be reviewing specs, then we could look at the potential extensibility points in relation to this. When this is more hashed out, then we could have some guidance for web devs around extensibility - and how do web devs plan to use these extensibility points
- 14:03:27 [marcosc]
- JeniT: is this what you guys (alex, yehuda) had in mind?
- 14:03:37 [marcosc]
- yehuda: yes
- 14:03:40 [marcosc]
- alex: yes
- 14:04:31 [marcosc]
- plinss: what we don't want is here is a feature and here is the extensibility points for feature X. Instead, we (TAG) want to look at what the lower level primitives are.
- 14:05:13 [marcosc]
- plinss: what JeniT is suggesting is that we identify the underlying extensibility points
- 14:05:39 [marcosc]
- JeniT: it would be useful in a document to specify through different examples
- 14:06:23 [marcosc]
- yehuda: when we notice something like fetch, we should make sure that groups don't redefine things over and over
- 14:07:23 [marcosc]
- alex: trying to find the right point at which to target their API (high low level)... this is hard to do.
- 14:07:39 [ht]
- ack next
- 14:07:40 [Zakim]
- ht, you wanted to ask why you're using a new tag
- 14:07:44 [marcosc]
- JeniT: it might be easier to do that if we have some document the describes this
- 14:08:09 [marcosc]
- plinss: this also ties in with working with other working groups
- 14:08:13 [ht]
- s/ht, you wanted to ask why you're using a new tag/[overtaken]/
- 14:08:28 [marcosc]
- plinss: it's our role to provide guidance wrt architecture
- 14:08:33 [marcosc]
- plinss: to other groups
- 14:08:45 [marcosc]
- dan: so, how does that translate into actions
- 14:09:02 [slightlyoff]
- annevk: from me, with love: https://github.com/slightlyoff/ZOMGWebIDL/blob/master/firefox/create_fails.md
- 14:09:36 [annevk]
- slightlyoff: why is URL there?
- 14:09:39 [annevk]
- slightlyoff: or Text?
- 14:09:52 [annevk]
- slightlyoff: or ProcessingInstruction or the others I mentioned earlier?
- 14:09:57 [marcosc]
- ACTION: yehuda and alex will create an initial draft of high level view/survey and how they relate to system capabilities
- 14:09:57 [trackbot]
- Created ACTION-809 - And alex will create an initial draft of high level view/survey and how they relate to system capabilities [on Yehuda Katz - due 2013-06-05].
- 14:10:15 [JeniT]
- ah, from previous meeting: https://gist.github.com/wycats/5205250
- 14:10:42 [slightlyoff]
- annevk: https://github.com/slightlyoff/ZOMGWebIDL/blob/master/firefox/create.html#L437
- 14:10:52 [slightlyoff]
- dka_: lawls.
- 14:10:57 [marcosc]
- yehuda: we can't obviously do too many APIs in the time we have, but we could for instance start with the Web audio API and how it might relate to the audio tag
- 14:11:13 [annevk]
- slightlyoff: I see, you're using a browser
- 14:11:23 [annevk]
- slightlyoff: well yeah, they're broken
- 14:11:34 [slightlyoff]
- noah: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
- 14:11:39 [marcosc]
- [BREAK]
- 14:11:48 [annevk]
- (although nightlies are getting better)
- 14:11:52 [slightlyoff]
- noah: in particular https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html#shadow-dom-section
- 14:12:12 [slightlyoff]
- annevk: feel free to send me edits to the md file
- 14:36:30 [dka_]
- dka_ has joined #tagmem
- 14:40:43 [noah]
- noah has joined #tagmem
- 14:48:17 [marcosc]
- TOPIC: capability URLs
- 14:49:31 [marcosc]
- [JeniT presents slides: http://w3ctag.github.io/presentations/reveal/capability-urls.html]
- 14:55:38 [slightlyoff]
- annevk: moved the file: https://github.com/slightlyoff/ZOMGWebIDL/blob/master/create_fails.md
- 14:56:30 [annevk]
- slightlyoff: so, I don't think I'm going to go through that thing again and edit it for now
- 14:56:44 [annevk]
- slightlyoff: it's useful enough as is
- 14:56:49 [slightlyoff]
- oh, you had edited it?
- 14:56:55 [slightlyoff]
- annevk: send me your edit
- 14:57:10 [annevk]
- no haven't
- 14:57:24 [annevk]
- sorry for the confusion, meant to look through it and remove those that are handled by specs
- 14:57:30 [slightlyoff]
- oh, OK
- 14:57:33 [slightlyoff]
- I can do that
- 14:59:42 [marcosc]
- [JeniT presents slides... Web Arch... ]
- 15:00:00 [marcosc]
- annevk: I feel like you are conflating a whole bunch of stuff together in this slide
- 15:00:18 [marcosc]
- noah: a fair amount is explained in the document
- 15:00:35 [marcosc]
- JeniT: I agree, there is more to go into there..
- 15:00:56 [marcosc]
- Slide - beyond single page
- 15:01:07 [marcosc]
- slide - recommendations
- 15:01:16 [marcosc]
- slide - application design
- 15:01:26 [annevk]
- So it seems the architecture concern doesn't apply here: http://www.w3.org/TR/webarch/#uri-aliases
- 15:01:34 [annevk]
- It talks about network effects, but here you want to keep them secret
- 15:01:38 [marcosc]
- JeniT: we should make some recommendations about this (we === tag)
- 15:01:45 [annevk]
- So you don't want network effects :)
- 15:01:54 [noah]
- It seems to me that capability URIs, by conflating identity with access rights, tend to break one of the main use cases for the Web: I want to provide to you a link to an interesting resource, and the access you have should depend on >your< rights, not mine.
- 15:02:09 [marcosc]
- slide - capability URL design
- 15:02:31 [ht]
- I note (Yves???) that HTTPbis has _removed_ the only mention I can find of https not being (publicly) cached: http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2040
- 15:02:34 [noah]
- I think capability systems are really interesting, but I'm suspicious of the merits of tunneling a capability architecture through the Web, which is not inherently capability-oriented.
- 15:03:22 [marcosc]
- yehuda: there are not good answers to these problems. I don't know the answer.
- 15:03:31 [marcosc]
- JeniT: that's what makes it interesting work
- 15:03:36 [Yves]
- ht, as they are not reaching proxies, that's normal
- 15:04:11 [marcosc]
- yehuda: I can live with password resets, and emailed URLS... but accessing gists, etc. is not so good.
- 15:04:19 [ht]
- Yves, where is _that_ noted? All I see is that the trajectory must be secured from end to end. . .
- 15:04:22 [noah]
- From Web arch:
- 15:04:30 [noah]
- "It is reasonable to limit access to a resource (for commercial or security reasons, for example), but merely identifying the resource is like referring to a book by title. In exceptional circumstances, people may have agreed to keep titles or URIs confidential (for example, a book author and a publisher may agree to keep the URI of page containing additional material secret until after the
- 15:04:30 [noah]
- book is published), otherwise they are free to exchange them."
- 15:04:31 [marcosc]
- JeniT: the document may describe the implications
- 15:04:40 [marcosc]
- JeniT: if you do X, then Y may happen
- 15:04:48 [ht]
- q+ to talk about actually secure capability URI designs
- 15:05:21 [marcosc]
- yehuda: it's a problem that URLs can be leaked when they are supposed to be private
- 15:06:45 [marcosc]
- [conversation about issues]
- 15:07:10 [ht]
- ack next
- 15:07:11 [Zakim]
- ht, you wanted to talk about actually secure capability URI designs
- 15:07:12 [dka_]
- q?
- 15:07:13 [marcosc]
- yehuda: it's a real failing that people can leak the urls
- 15:07:20 [noah]
- q?
- 15:07:39 [marcosc]
- ht: there are strategy to address this issue, but it's complicated.
- 15:08:51 [marcosc]
- ht: I would like to give the ability to one site to write resources to another site - but with rules (e.g., 10 per day, once a month). I.e., you allow a capability without actually acting as the user.
- 15:09:17 [Yves]
- ht, see rfc2818 for https
- 15:09:21 [marcosc]
- ht: these things exist, but they are complicated.
- 15:10:33 [marcosc]
- ht: it's often a 3 actor situation ... or a trusted 4th party. This stuff is a bit of rocket science right now, so I suggest that we don't publish anything that doesn't acknowledge existing capability systems.
- 15:11:19 [ht]
- s/so I/but I do/
- 15:11:26 [marcosc]
- noah: the ones that I've seen are built on systems similar to unix
- 15:11:58 [dka_]
- q?
- 15:12:33 [marcosc]
- [discussion about various types of capability systems]
- 15:13:42 [marcosc]
- dan: what we are talking about here is to help people do what they are doing already
- 15:13:47 [noah]
- q?
- 15:13:50 [noah]
- q+ noah
- 15:14:02 [marcosc]
- alex: is this something that we should encourage them to do?
- 15:14:13 [marcosc]
- annevk: we should document the concerns around this
- 15:14:22 [marcosc]
- dan: some of the best practices
- 15:15:11 [marcosc]
- noah: what are the responsibilities of the user agents? For the web platform, it would be good to clarify what happens when one of these URLs leaks.
- 15:15:12 [dka_]
- ack noah
- 15:15:46 [marcosc]
- noah: there is an obligation for the TAG to clarify this for user agents, or proxies, to handle this.
- 15:16:10 [marcosc]
- noah: and you need to explain how to do this without for example using a HTTP header or some other solution
- 15:16:22 [dka_]
- q+
- 15:16:51 [marcosc]
- noah: I expect to be able to mail URLs, but there should be some level of protection at the UA level
- 15:17:13 [marcosc]
- yehuda: there is certainly a social norm issue of sharing URIs
- 15:18:01 [dka_]
- ack me
- 15:18:02 [noah]
- q-
- 15:19:14 [marcosc]
- dan: before we start making recommendations, it seems to me that there are some best practices around capability URLs that could be documented.
- 15:19:37 [marcosc]
- s/start making recommendations/start making recommendations to UAs and proxies/
- 15:19:38 [ht]
- Yves, HTTPbis explicitly says it supersedes 2818
- 15:19:44 [noah]
- Again, my recommendation was to document the current platform rules: what are the responsibilities, of server, proxy, user agent and other Web code to protect or prevent copying of certain URIS.
- 15:20:16 [noah]
- With that in hand, we can consider 1) explaining the pros and cons of capability URIs and maybe 2) recommending mechanisms for controlling such things.
- 15:20:38 [marcosc]
- annevk: I still want these things cached (or still be in location bar)
- 15:20:43 [noah]
- FWIW, and this will be no news to long-time TAG members, I'm not a fan of trying to tunnel capability capbility :-) through the Web
- 15:21:24 [ht]
- Yves, ah, not supersedes, but updates
- 15:21:25 [marcosc]
- timbl: capability urls are relatively rare when compared to other urls
- 15:21:42 [marcosc]
- ht: I used two today
- 15:21:47 [ht]
- Yves, hmm, really not clear what's still normative in 2818 and what's overtaken
- 15:21:52 [ht]
- s/today/yesterday/
- 15:21:56 [Yves]
- indeed
- 15:22:15 [marcosc]
- timbl: so you are suggesting best practice aimed at web devs, as opposed to UAs and proxies
- 15:22:27 [marcosc]
- dan: What existing material is out there that we could build on?
- 15:22:51 [marcosc]
- JeniT: there are some links in the slides, which is what I've found through searching
- 15:23:50 [marcosc]
- dan: do we know if there are any internal recommendations about capability URLs?
- 15:24:00 [marcosc]
- annevk: I suspect not
- 15:24:30 [marcosc]
- JeniT: maybe Google has something?
- 15:24:52 [marcosc]
- annevk: the links in the presentation are from google guys
- 15:26:02 [marcosc]
- alex: Tyler has worked on a bunch of stuff related to this. Teams at Google often have their own thing - but I don't want to misrepresent what they are doing.
- 15:26:28 [marcosc]
- dan: JeniT, are you proposing to be an editor of this?
- 15:26:35 [marcosc]
- JeniT: yes
- 15:26:41 [marcosc]
- annevk: I'm happy to help review stuff
- 15:27:16 [marcosc]
- plinss: do you see this as being a note or rec track doc?
- 15:27:37 [marcosc]
- JeniT: right now, it's just about writing up stuff... we can decide what to do with it later
- 15:27:46 [marcosc]
- plinss: I'm interested in scope
- 15:27:53 [marcosc]
- plinss: is all
- 15:28:16 [marcosc]
- JeniT: that's all I need
- 15:29:04 [Norm]
- Norm has joined #tagmem
- 15:29:21 [marcosc]
- ACTION: Jeni to create a first draft of capability document guidelines
- 15:29:21 [trackbot]
- Created ACTION-810 - Create a first draft of capability document guidelines [on Jeni Tennison - due 2013-06-05].
- 15:29:40 [marcosc]
- alex: do we have consensus if we want to do this?
- 15:30:06 [marcosc]
- annevk: we should describe the landscape
- 15:30:49 [marcosc]
- dan: one of the early slides said that this contravenes WebArch.. is that something that should be discussed.
- 15:30:57 [marcosc]
- timbl: that is one of the least worrying bits
- 15:31:43 [marcosc]
- noah: I happen to like this rule... lets chip away at Web Arch
- 15:31:55 [marcosc]
- s/lets/let's
- 15:32:18 [marcosc]
- noah: I think it would be good to enhance web arch with regards to this matter
- 15:32:45 [marcosc]
- noah: either explain don't do that, or explain the trade off
- 15:41:47 [JeniT]
- yehuda: there's one thing that people could do, which is have a one-off capability URL that upgrades to a cookie
- 15:42:20 [JeniT]
- alex: there's a strong timing component, usually they should be short-lived
- 15:43:01 [JeniT]
- yehuda: like you could enter your phone number, and then have to enter a passcode that's been SMSed to you every time you want to access it after that
- 15:44:06 [marcosc]
- TOPIC: HTTP Bis
- 15:45:59 [marcosc]
- ht: the focus of my interest is in basic arch properties as a whole, but not so much on browsers. But I wanted to tell you a little bit about one of the long running issues. Which is, what URIs are and how they hold the web together (if they do!). RFC2616 is the one being replaced - it is over 10 years old.
- 15:47:08 [marcosc]
- ht: it has been being edited for over 3 years, which is exceptions for the IETF. One of the things the TAG has tried to help with is the arch is in the "identifier" part of the URI. We have pushed the IETF to be clear about URIs.
- 15:48:01 [marcosc]
- ht: this is not because we are architecture astronauts. its because question have arisen about how the URIs are used on the "vanilla web" VS the semantic web
- 15:48:18 [marcosc]
- ht: if there is a difference, then how should those differences be expressed?
- 15:49:06 [marcosc]
- ht: so I've been going through the specs, fairly carefully. To try to see what picture is emerging. If you just read this spec as if you had no background in HTTP/s, what would a reader get out of that?
- 15:49:54 [marcosc]
- ht: if people are interested in this topic, I encourage people to read the intro sections and the email I sent to the TAG member list
- 15:50:13 [marcosc]
- ht: I will send the email to the public list soon
- 15:50:34 [marcosc]
- ht: Roy has added more language about REST.
- 15:51:00 [marcosc]
- yehuda: I'm lacking context about REST... i know what it is, but how does it relate to this?
- 15:52:18 [marcosc]
- timbl: for me, the arch of the web is the hash... [tim describes how the web work and how the semantic web works in a rapid fire manner]
- 15:55:47 [marcosc]
- ht: ... at the end of the day, this only really matters for spec weenies what URIs mean.
- 15:56:32 [annevk_]
- annevk_ has joined #tagmem
- 15:56:32 [marcosc]
- ht: devs are really only interested in operational stuff like status codes, cache control.
- 15:57:56 [marcosc]
- ht: so I wanted to give you an overview of the comments I'm making about the document. But what would be say about URIs if this was up to the TAG?
- 16:00:09 [marcosc]
- ht: what we should say, if we could, the biggest gap from my perspective what is people's behaviour with regards to this technology have to be ... to lead the web to it's full potential? We need to identify who the players are, and what their obligations are with regards to using URIs - i.e., what is the social contract.
- 16:01:32 [marcosc]
- ht: the spec assumes human expectations about how people use URIs
- 16:01:54 [marcosc]
- ht: but there are all sort of assumptions about what people do
- 16:02:07 [annevk]
- annevk has joined #tagmem
- 16:02:24 [marcosc]
- ht: I'm going to send a few comments back to the HTTP bis WG. But is there other stuff I should do?
- 16:02:53 [marcosc]
- ht: one of the things people would like to know, when I get a 200?
- 16:02:59 [marcosc]
- annevk: that's it's OK?
- 16:03:08 [marcosc]
- [room laughs]
- 16:03:23 [marcosc]
- ht: but what does that mean as a social contract?
- 16:03:42 [marcosc]
- timbl: but to make this part of the TAG, we need to look at the applicability of this
- 16:04:31 [marcosc]
- ht: right now, it's not clear what the semantics are with regards to method
- 16:05:30 [marcosc]
- annevk: httpbis can't change the state of the world. But they can try to fix bugs in implementations. But they should just leave the philosophy to a primer or something else
- 16:05:58 [marcosc]
- noah: it's good to be clear about the semantic difference between GET, POST, etc.
- 16:06:35 [marcosc]
- noah: it's a bit of a grey area, so you have to be careful about what is defined
- 16:08:16 [marcosc]
- [discussion about philosophy behind different GETs]
- 16:09:49 [JeniT]
- [annevk's conneg rant]
- 16:09:50 [marcosc]
- [discussion about conneg...]
- 16:10:10 [JeniT]
- [wycats_'s pro conneg rant]
- 16:10:35 [marcosc]
- [...interpretive dance about bags of bits.... ]
- 16:13:37 [marcosc]
- dan: we might have a TAG deliverables that updates URLs and URIs and discusses that
- 16:14:05 [marcosc]
- ht: I have a working title: "what would it be like to document what is true about URLs?"
- 16:15:11 [marcosc]
- ht: asking them to get rid of philosophising would be counter productive
- 16:15:37 [marcosc]
- s/them/the HTTP Bis WG/
- 16:16:06 [marcosc]
- ht: what I am reviewing is just a clarifications of HTTP 1.0 - it's a cleanup
- 16:18:40 [wycats_]
- I assume you mean 1.1?
- 16:18:55 [annevk]
- yes
- 16:19:02 [marcosc]
- s/HTTP 1.0/HTTP 1.1
- 16:19:37 [marcosc]
- TOPIC: F2F Planning
- 16:20:01 [marcosc]
- 13-15 Oct at MIT
- 16:20:27 [marcosc]
- noah: 13-15 Oct at MIT, we also identified, week of Jan 06.
- 16:26:35 [marcosc]
- [discussion about TPAC, Marcos being booted from the tag, etc. ]
- 16:35:37 [dka_]
- dka_ has joined #tagmem
- 16:35:51 [JeniT]
- Jan 7-9 in Europe
- 16:42:25 [marcosc]
- TOPIC: Polyglot
- 16:42:41 [marcosc]
- ht: we've said everything we want to say.
- 16:42:58 [marcosc]
- yehuda: I think we reached consensus on this already
- 16:43:13 [marcosc]
- ht: is there a link to the discussion?
- 16:44:19 [JeniT]
- https://lists.w3.org/Archives/Member/tag/2013Apr/0046.html
- 16:44:26 [marcosc]
- ht: the background is that Paul Cotton asked to clarify where we are at
- 16:45:07 [ht]
- http://www.w3.org/2001/tag/group/track/actions/791
- 16:45:47 [marcosc]
- yehuda: we all agreed that we can all live with the proposed text.
- 16:46:27 [marcosc]
- ht: we should consider Larry's feedback
- 16:46:49 [marcosc]
- annevk: I don't agree with the change Larry suggests. I think it's wrong
- 16:46:58 [marcosc]
- yehuda: I agree.
- 16:47:08 [marcosc]
- annevk: it could be clearer
- 16:47:53 [JeniT]
- email should s/wether/whether/
- 16:48:40 [marcosc]
- annevk: it would be clearer if with xhtml mime type you use xhtml, and with html mime type you use html
- 16:49:48 [marcosc]
- ht: if we could capture the above in the proposed text, then that would be great.
- 16:49:48 [annevk]
- see also http://html-differences.whatwg.org/#syntax which describes that
- 16:51:09 [ht]
- My proposed change "using HTML5 syntax and mediatypes (either HTML syntax and text/html, or XHTML syntax and application/xhtml+xml"
- 16:55:17 [marcosc]
- yehuda: in the Web Arch document there is a section that talks about the content-type in normative terms that don't match reality.
- 16:56:11 [annevk]
- http://www.w3.org/TR/CSS1/
- 16:56:11 [marcosc]
- ht: we can't just change the spec in place
- 16:56:24 [noah]
- What change to what spec is being proposed?
- 16:56:44 [Yves]
- it's actually a new spec
- 16:57:05 [ht]
- http://www.w3.org/2001/tag/webarch/errata.html
- 16:57:06 [noah]
- I thought Yehuda said: "Published spec XXX says MUST" which one?
- 16:57:22 [marcosc]
- http://www.w3.org/TR/webarch/
- 16:57:36 [marcosc]
- yehuda: section 3.3
- 16:57:46 [annevk]
- "Agents MUST NOT ignore message metadata without the consent of the user."
- 17:00:06 [marcosc]
- noah: the TAG should take a strong line that normative spec should be followed.
- 17:00:47 [marcosc]
- noah: it would be better to get the normative text updated in the appropriate spec
- 17:00:48 [ht]
- Stand by for HTTPbis:
- 17:00:50 [ht]
- In practice, resource owners do not always properly configure their
- 17:00:50 [ht]
- origin server to provide the correct Content-Type for a given
- 17:00:50 [ht]
- representation, with the result that some clients will examine a
- 17:00:50 [ht]
- payload's content and override the specified type. Clients that do
- 17:00:50 [ht]
- so risk drawing incorrect conclusions, which might expose additional
- 17:00:50 [ht]
- security risks (e.g., "privilege escalation"). Furthermore, it is
- 17:00:50 [ht]
- impossible to determine the sender's intent by examining the data
- 17:00:51 [ht]
- format: many data formats match multiple media types that differ only
- 17:00:51 [ht]
- in processing semantics. Implementers are encouraged to provide a
- 17:00:51 [ht]
- means of disabling such "content sniffing" when it is used.
- 17:02:46 [marcosc]
- ht: given the normative text comes from 2616, the appropriate text in Web Arch should be updated when HTTP Bis updates the HTTP 1.1 spec.
- 17:02:52 [ht]
- trackbot, Action-791?
- 17:02:52 [trackbot]
- ACTION-791 -- Alex Russell to redraft proposed "status" section that TAG is suggesting for Polyglot -- due 2013-04-16 -- OPEN
- 17:02:52 [trackbot]
- http://www.w3.org/2001/tag/group/track/actions/791
- 17:03:00 [ht]
- trackbot, close action-791
- 17:03:00 [trackbot]
- Closed ACTION-791 Redraft proposed "status" section that TAG is suggesting for Polyglot.
- 17:03:11 [marcosc]
- Dan: so, Polyglot can be closed.
- 17:07:26 [marcosc]
- [MEETING ADJOURNED]
- 17:10:27 [marcosc]
- marcosc has joined #tagmem
- 17:21:34 [Zakim]
- Zakim has left #tagmem