08:12:49 <RRSAgent> RRSAgent has joined #tagmem
08:12:49 <RRSAgent> logging to http://www.w3.org/2013/05/30-tagmem-irc
08:12:51 <trackbot> RRSAgent, make logs public
08:12:51 <Zakim> Zakim has joined #tagmem
08:12:53 <trackbot> Zakim, this will be TAG
08:12:53 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
08:12:54 <trackbot> Meeting: Technical Architecture Group Teleconference
08:12:54 <trackbot> Date: 30 May 2013
08:13:19 <JeniT> Chair: Peter Linss, Dan Appelquist
08:13:30 <JeniT> Scribe: Jeni Tennison
08:13:33 <annevk> annevk has joined #tagmem
08:13:34 <JeniT> ScribeNick: JeniT
08:14:21 <JeniT> Present: Tim Berners-Lee, Yehuda Katz, Peter Linss, Anne van Kesteren, Alex Russell, Dan Appelquist, Yves Lafon, Henry Thompson
08:14:35 <JeniT> Present+ Noah Mendelsohn
08:14:46 <JeniT> Present+ Marcos Caceres
08:15:12 <noah> noah has joined #tagmem
08:15:49 <JeniT> Agenda: http://www.w3.org/wiki/TAG/Planning/May-2013-F2F
08:16:28 <marcosc> marcosc has joined #tagmem
08:17:04 <JeniT> Topic: Noah's thoughts as outgoing chair
08:17:14 <JeniT> noah: I hope to keep this short
08:17:45 <JeniT> ... I've been on the TAG for 9 years
08:17:54 <JeniT> ... chair for 4 years
08:18:12 <JeniT> ... the role of the chair is to help the group think about what success is, and to help them deliver
08:18:29 <JeniT> ... there are lots of new people in the group, and it's reinventing itself, and that's great
08:18:59 <JeniT> ... none of this should be seen as an intention to stop you doing the things you're doing
08:19:00 <timbl> timbl has joined #tagmem
08:19:28 <JeniT> ... these are reflections for longer term
08:19:34 <JeniT> ... this is an unusual group
08:19:50 <JeniT> ... other groups have clear deliverables, and customers waiting for your work, who want to build on it
08:20:10 <JeniT> ... there's a route for feedback in working groups
08:20:16 <JeniT> ... we don't have that in the TAG
08:20:43 <JeniT> ... one failure mode is thrashing on stuff that isn't focused
08:21:02 <JeniT> ... worth reflecting on what the scope of the TAG is, and having 70-80% of the work fitting within that scope
08:21:11 <JeniT> ... you are the senior technical steering committee for the web
08:21:20 <JeniT> ... the only other steering committee does finances and stuff
08:21:36 <JeniT> ... and the web is a really important piece of infrastructure
08:21:49 <JeniT> ... evolving much faster than the phone system etc
08:22:00 <JeniT> ... you have responsibility for a system that's really important and touches a lot of things
08:22:06 <JeniT> ... from time to time think about it that way
08:22:13 <JeniT> ... stretch out beyond your comfort zone sometimes
08:22:24 <JeniT> ... you all have expertise in lots of important stuff
08:22:37 <noah> noah has joined #tagmem
08:22:38 <JeniT> ... for example, when Henry brought up the use case of librarians
08:23:00 <JeniT> ... and whether they could use URIs given the persistence they need
08:23:13 <JeniT> ... from time to time ask where the opportunities are
08:23:23 <JeniT> ... you have to ask what makes the web different and valuable
08:23:37 <JeniT> ... my answer comes back to Metcalf's Law, or network effects
08:23:55 <JeniT> ... a virtuous positive feedback cycle where adding things to the network adds value to the whole web
08:24:20 <JeniT> ... that gives you an imperative to think about things like how international the web is
08:24:43 <JeniT> ... there was a time when putting a web server in a printer would have seemed weird
08:24:49 <JeniT> ... now we take it for granted
08:25:02 <JeniT> ... the TAG needs to think crazy like that, with some guiding principles
08:25:28 <JeniT> ... ask yourself about whether it's worth being able to link data into the rest of the web
08:25:38 <JeniT> ... you can get very busy working on stuff that you know is important
08:25:52 <JeniT> ... web app developers are not a reliable proxy for everyone you have to worry about
08:26:00 <JeniT> ... they're not a proxy for librarians for example
08:26:13 <JeniT> ... this is a plea to think about the potential and the risks for the web
08:26:22 <JeniT> ... this forces you to go outside your comfort zone
08:26:39 <JeniT> ... don't just keep in touch with the communities that you know about
08:26:54 <JeniT> ... the other thing I'd say is that we're the architectural group, and it's not entirely clear what that means
08:27:05 <JeniT> ... this group should make sure the web works in 30/50/100 years
08:27:32 <JeniT> ... phone numbers were built to scale, they scale to mobile
08:27:56 <JeniT> ... think about building to scale
08:28:14 <JeniT> ... for example, I think the surface area should be kept small
08:28:25 <JeniT> ... you can decide what matters, I'd encourage you to think about it, to try
08:28:53 <JeniT> ... it's easy to make decisions in an agile way when you have contact with your users, in an agile way
08:29:16 <JeniT> ... but it's an art to make design decisions without that, as Tim did
08:29:36 <JeniT> ... I'd encourage you to look at Tim's design notes
08:29:45 <JeniT> ... a lot of what's in WebArch is a clarification and cleanup of those thoughts
08:29:51 <JeniT> ... that doesn't make them all right
08:30:10 <JeniT> ... but if you're on the TAG, I'd encourage you to look at the decisions that Tim made
08:30:28 <JeniT> ... sometimes you should stand up to people, making longer term decisions
08:31:15 <JeniT> ... when you do these things you can be wrong
08:31:56 <JeniT> ... for example, we could see long term benefits with XHTML, and eventually the community came back and said it was wrong
08:32:08 <JeniT> ... the three pillars of web architecture are URIs, HTTP and HTML
08:32:43 <JeniT> ... Tim has said in order of importance they are URIs, HTTP and then content stuff (HTML, CSS, JS)
08:32:57 <JeniT> ... a lot of stuff we're looking at at the moment is in the third category
08:33:09 <JeniT> ... you should look for things in the first two categories
08:33:12 <JeniT> ... in particular linking
08:33:18 <JeniT> ... because that's what makes the network
08:33:39 <JeniT> ... the reason people don't stay in iPhone Apps is because they want to visit other things on the network
08:33:59 <JeniT> ... that's why it's important to think about unique names
08:34:20 <JeniT> ... for example, what about internationalised names?
08:34:32 <JeniT> ... one last thing
08:34:52 <JeniT> ... it took me a while to realise how many ways Tim's presence adds to the group
08:35:05 <JeniT> ... Tim works on a much broader range of this stuff than most of us do
08:35:31 <JeniT> ... I'd encourage you to find ways to take advantage of not only his smarts and expertise, but also the scope of his knowledge and work
08:35:52 <JeniT> ... finally
08:36:05 <JeniT> ... because there's no one asking for things
08:36:14 <JeniT> ... you have to be very motivated
08:36:42 <JeniT> ... there's a huge amount of stuff to go out and proactively get into
08:36:50 <JeniT> ... work hard, make it easy for your chairs
08:36:55 <JeniT> ... and thank you
08:37:06 <JeniT> ... thank you for Tim for making me part of this
08:37:20 <JeniT> timbl: thank you for chairing for such a long time, and for your contributions
08:37:33 <JeniT> ht: I'd like to follow up on one thing that noah said
08:37:45 <JeniT> ... W3C has not done as well as we wish we had at having user representatives highly visible
08:38:01 <JeniT> ... there are a handful of people who are clients
08:38:15 <JeniT> ... users are underrepresented in the W3C
08:38:27 <JeniT> ... they're a constituency that the TAG needs to keep in view, because no one else is going to do that
08:38:42 <JeniT> ... that's a corollary of noah's point that the dev community are not the only customers
08:38:48 <JeniT> ... not the only people we're responsible to
08:39:04 <JeniT> ... trying to balance the requirements of different classes of user agents and different types of users are really important
08:39:26 <JeniT> dka_: the point about linking is really important, one of the things I want to bring up in the packaging discussion
08:39:37 <JeniT> ... how do we have a packaged app and still use linking
08:39:47 <JeniT> ... if it's possible, should we be influencing the work in that way
08:40:06 <JeniT> Topic: Futures / Promises
08:41:42 <JeniT> slightlyoff: we often create APIs which take the form dothing(opt1, ..., callback)
08:41:51 <JeniT> ... where callback is a function that takes a single value
08:42:20 <JeniT> timbl: where the value passed in is the context
08:42:31 <JeniT> noah: you get context from the closure
08:43:16 <JeniT> slightlyoff: the simple synchronous version is contents = read(opt1, ...)
08:43:26 <JeniT> ... in the synchronous version you'd wrap it in a try/catch
08:43:33 <JeniT> ... that doesn't work in an async version
08:43:47 <JeniT> ... so you end up another parameter for the error, or you have a separate error handler callback
08:44:01 <JeniT> ... this shows up in a lot of APIs
08:44:11 <JeniT> ... often when you're doing IO
08:44:40 <JeniT> timbl: the contract is that you'll get only the main callback or the error callback called?
08:44:53 <JeniT> slightlyoff: it happens on a WG by WG and API by API basis
08:45:10 <JeniT> ... there are all kinds of patterns
08:45:20 <JeniT> ... you might get an operation handle back
08:45:37 <JeniT> ... op = read(...);
08:46:01 <JeniT> ... op.onsuccess(...).ondone(...).onreadystatechange(...).onprogress(...)
08:46:06 <JeniT> ... there are many different names for success
08:46:31 <JeniT> ... they all reify down to a single event handler
08:46:56 <JeniT> ... function(evt) { var controls = evt.value, evt.contents etc }
08:47:25 <JeniT> ... there's a temporal dead zone between reading and binding event handlers
08:48:04 <JeniT> marcosc: this is freaking awful
08:48:34 <JeniT> slightlyoff: what people end up with is that they do the callbacks at some time in the future
08:48:50 <JeniT> ... this can be linked into the HTML event loop
08:48:58 <JeniT> ... some APIs define this well, some don't
08:49:07 <JeniT> ... it's weird, it's verbose, there's inconsistencies
08:50:19 <JeniT> ... it makes it hard for developers to work with
08:50:29 <JeniT> noah: almost every OS eventually gets an eventing system
08:50:38 <JeniT> slightlyoff: we should be driving towards a standard way of doing this
08:50:42 <JeniT> ... this shouldn't be hard
08:51:10 <JeniT> timbl: what you're trying to do is express something in a synchronous kind of way in a asynchronous world
08:51:22 <JeniT> slightlyoff: promise = read(...);
08:51:37 <JeniT> noah: there's a type that is returned by read() which is consistent across APIs
08:52:13 <JeniT> slightlyoff: that's right, you can have p.then(func(v) {}, func(e) {}).then(...)
08:53:01 <JeniT> slightlyoff: then is called immediately but the functions aren't
08:53:34 <JeniT> noah: the read() delivers the value to the promise, the promise delivers the values to the functions
08:53:47 <JeniT> slightlyoff: you can call then multiple times
08:54:02 <JeniT> timbl: the thens occur in any order?
08:54:10 <JeniT> slightlyoff: they're dispatched in the order they're registered
08:54:52 <JeniT> ht: how does f2 know the name of the promise?
08:54:58 <JeniT> ... how does it chain?
08:56:22 <JeniT> slightlyoff: the then() creates a new future
08:56:38 <JeniT> ... so you can chain another then() on that future
08:57:00 <JeniT> ... this is an important standard way of doing this historically
08:57:12 <JeniT> ... many languages have this, for example Python has futures
08:57:38 <JeniT> ... Javascript has no syntactic support for it, so it's just through these functional contracts
08:57:47 <JeniT> ... C++ has Futures for example
08:58:04 <JeniT> ... JS has gotten by with libraries that are similar to this
08:58:16 <JeniT> ... they're really common, and people are using this pattern at scale
08:58:27 <JeniT> ... so we want to get our house in order from the DOM perspective
08:58:58 <JeniT> ht: if there's no language-level support for this, how do the libraries which implement these solve the race condition problem?
08:59:05 <JeniT> ... if they have to just work with callbacks
08:59:33 <JeniT> slightlyoff: in the web platform we have several APIs that give us the ability to delay work for the next turn
08:59:46 <JeniT> ... they give you the ability to run code soon but not synchronously
08:59:54 <JeniT> timbl: timeout(0) for example
09:00:21 <JeniT> slightlyoff: JS and the DOM get along but don't have a contract
09:00:26 <JeniT> ... JS has no idea of an event loop
09:00:47 <JeniT> ... we're hoping to add something in ES7
09:01:01 <JeniT> ... the DOM has been responsible for everything to do with time, except getting the time from the system clock
09:01:15 <JeniT> ... the libraries use a call-me-back-soon hook
09:01:59 <JeniT> [discussion of GC]
09:02:28 <JeniT> noah: for medium/high performance this'll give you what you need
09:02:45 <JeniT> slightlyoff: this gives you standard ways for error handling too
09:03:28 <JeniT> timbl: I've found things get lost currently, do we get a guarantee that one of these things get called?
09:03:32 <JeniT> slightlyoff: I will talk about that later
09:04:31 <JeniT> ... there are lots of libraries, want to make them compatible, have made Promises A+
09:05:47 <JeniT> ... a proto-standard scrum, to standardise just the essential pieces of this contract
09:05:56 <JeniT> ... eg number of arguments, the timing
09:06:01 <JeniT> ... not the rest of the API design
09:06:05 <JeniT> ... DOM needs this badly
09:06:09 <JeniT> ... JS needs it too
09:06:12 <JeniT> timbl: which bits?
09:06:22 <JeniT> slightlyoff: generators and iterators which are nearly pythonic in their style
09:06:32 <JeniT> ... and which aren't explained, they're just syntax
09:06:40 <JeniT> ... it would be nice if we could describe them as promises
09:07:11 <JeniT> ... in most cases we're on the UI thread
09:07:15 <JeniT> wycats_: we need them for modules
09:07:34 <JeniT> slightlyoff: it helps us reason about IO
09:07:45 <JeniT> ... it would be good if both DOM and JS had a standard contract for their users
09:08:08 <JeniT> ... since January we've been working with the Promises A+ community and the library authors
09:08:37 <JeniT> wycats_: all the pure JS libraries have coalesced around this
09:09:01 <ht> ht has joined #tagmem
09:09:10 <JeniT> slightlyoff: annevk's draft locks down the ambiguities
09:09:15 <JeniT> ... this is good for DOM
09:09:48 <JeniT> ... we can make backwards-compatible fixes to existing APIs by returning a promise rather than void
09:10:03 <JeniT> ... we want to make sure that APIs standardise around this same pattern
09:10:13 <JeniT> timbl: so this has consensus?
09:10:21 <JeniT> slightlyoff: there's no active hostility
09:10:28 <JeniT> annevk: there's some debate about specifics
09:10:37 <JeniT> slightlyoff: this was a hot topic at TC39 last week
09:11:18 <JeniT> ... the big change is that we've renamed 'Future' to 'Promise'
09:11:44 <JeniT> timbl: was there any change to semantics?
09:11:47 <JeniT> slightlyoff: no
09:11:56 <JeniT> ... there are two camps about how to use these things in the wild
09:12:07 <JeniT> ... generally coming from perspectives of producer vs consumer
09:12:19 <JeniT> ... the Promise can be thought of as the value
09:12:28 <JeniT> ... or you can think of the value being received at another time
09:12:46 <ht> ht has joined #tagmem
09:13:05 <JeniT> wycats_: abashed monadic promises
09:13:30 <JeniT> slightlyoff: we've won this battle in TC39 and DOM
09:13:38 <JeniT> annevk: you should say 'platform APIs' rather than DOM
09:14:03 <JeniT> slightlyoff: yes, we have agreement to use the same design, and to coordinate
09:14:26 <wycats_> you should consider this TAG work
09:14:27 <JeniT> ... and it will eventually end up in the language
09:14:40 <JeniT> dka_: what can we as the TAG do, what's the output of our work on this?
09:14:52 <JeniT> ... and what external bodies should the TAG be influencing to get consensus & buy-in?
09:15:21 <JeniT> marcosc: from a WG perspective, where we've been trying to use these things is guidance on how to hook into the spec
09:15:25 <JeniT> ... like examples
09:15:30 <JeniT> annevk: the spec doesn't have hooks yet
09:15:55 <JeniT> marcosc: if the TAG made a document that gave examples for spec authors
09:16:04 <JeniT> ... to make sure we're using the right language
09:16:08 <JeniT> wycats_: an explainer
09:16:16 <JeniT> timbl: is there JS for implementing it?
09:16:23 <JeniT> slightlyoff: yes, I've written one for example
09:16:36 <JeniT> wycats_: (to DKA) you should consider this TAG work
09:16:50 <JeniT> dka_: making that assumption, what is the output of the TAG?
09:16:58 <JeniT> annevk: note on promises
09:17:14 <JeniT> wycats_: a 'how to make APIs' guide that fast-tracks Futures
09:17:34 <JeniT> dka_: it's useful to be able to point to a document in TAG space that has the links to the relevant work
09:17:52 <JeniT> marcosc: and bug annevk to make sure we can hook into the spec
09:17:57 <JeniT> slightlyoff: we're not finished on the spec
09:18:10 <JeniT> ... we've been successful at preventing design needs from leaking into the superclass
09:18:15 <JeniT> ... eg notification of progress
09:18:42 <JeniT> ... you need a subclass of a promise to give that
09:18:55 <JeniT> ... need to get agreement on common subclasses
09:19:19 <JeniT> ... the TAG could help spec authors understand how useful it is to have a common contract
09:19:38 <JeniT> ... we've backdoored this because libraries have agreed, just have to standardise it
09:19:50 <JeniT> ... the TAG should weigh in to say it's a good thing to do
09:20:04 <JeniT> timbl: have every jQuery implementation have a complete Promise API?
09:20:09 <JeniT> wycats_: it's an evolving story
09:20:17 <JeniT> slightlyoff: there are many opportunities here
09:20:26 <JeniT> ... if we have a standard platform Promise type it's possible to add tools
09:20:42 <JeniT> ... eg to show a list of outstanding promises that haven't been resolved
09:21:01 <JeniT> ... if we can't standardise on a type we can't do that
09:21:35 <JeniT> wycats_: all existing libraries can wrap jQuery promises to create ones that meet their APIs
09:21:50 <JeniT> timbl: what's nice about try/catch is you can wrap it around a whole bunch of stuff
09:22:00 <JeniT> annevk: you can combine promises into a new promise
09:22:24 <JeniT> wycats_: the design is to make it easy to express things as if they were synchronous
09:22:38 <JeniT> ... xhr.then(success).then(success2).then(null, err)
09:23:39 <JeniT> ... and that desugars into try { xhr(); success(); success2(); } catch (e) { err() }
09:24:14 <annevk> Yves, ETA is a week or two, not sure if you asked that
09:24:29 <annevk> Yves, ETA for renaming that is and fixing a few things
09:24:34 <Yves> yeah, I was asking for ETA on the new version of the spec
09:25:07 <JeniT> timbl: what you want to do is write an asynchronous case in as concise a way as sync ways
09:25:14 <JeniT> slightlyoff: we can't get there without this
09:25:35 <JeniT> wycats_: in unix you have file descriptors for example
09:25:47 <JeniT> ... but you need the abstraction first, something that represents the eventual thing from IO
09:25:54 <JeniT> ... you need the primitive first
09:25:57 <JeniT> slightlyoff: this is the primitive
09:26:11 <JeniT> ... and this is why I think the TAG needs to help drive this through the platform as quickly as possible
09:26:31 <JeniT> ... it would be best if all the platform APIs use this pattern
09:26:42 <JeniT> ... in the same way as we're relatively uniform over events
09:26:50 <JeniT> ... there will be a similar issue over Streams
09:26:58 <JeniT> ... there's no core idea of Streams
09:27:08 <JeniT> ... then ES7 will probably bite off language-native events
09:27:19 <JeniT> ... and it would be good to make sure that was unified with DOM events
09:27:25 <JeniT> ... from an architectural perspective
09:28:10 <JeniT> timbl: using a promise has an overhead but is the idea that in the future will the language optimise it?
09:28:31 <JeniT> slightlyoff: anything that's common enough will get optimised
09:28:38 <JeniT> ... especially if it's targeted by benchmarks
09:28:50 <JeniT> ... having it standard opens up possibilities for optimisation
09:29:08 <JeniT> ... it's never going to be actually free
09:29:18 <JeniT> wycats_: V8 happily optimises DOM constructs
09:29:29 <JeniT> slightlyoff: the more that V8 knows about the internal representation, the more it can do
09:29:59 <JeniT> plinss: what are the concrete next steps for the TAG?
09:30:10 <JeniT> slightlyoff: I need help convincing spec authors that this is a good thing to do
09:30:30 <JeniT> timbl: write what you think and we call it a Finding
09:30:39 <JeniT> ... then you get a TPAC slot to point people at it
09:30:50 <JeniT> dka_: I think that fits nicely in how we described our work
09:31:00 <JeniT> ... we have Note on Promises on the list
09:31:07 <JeniT> ... this gets into the question of how we operate
09:31:17 <JeniT> ... I'd like to see placeholder document for that before the end of the meeting
09:31:21 <JeniT> ... which we use as a reference point
09:31:32 <JeniT> ... if you have a commitment to write the content of the document, we can start shopping it around
09:31:43 <JeniT> ... we can use it as a basis for the group engagement that we talked about yesterday
09:31:53 <JeniT> ... even starting with discussion on web audio
09:32:09 <JeniT> plinss: we have to get consensus on whether this is something the TAG wants to throw its weight behind
09:32:25 <JeniT> ... TAG Finding + TPAC slot might be appropriate, but do we need something quicker than that?
09:32:49 <JeniT> marcosc: it's hard to move people off the events model, so it needs to be clear how and when to do that
09:32:59 <JeniT> wycats_: the explainer needs to go into benefits and limitations
09:33:17 <JeniT> timbl: common open source code too?
09:33:31 <JeniT> marcosc: Alex has done some work on IndexedDB & LocalStorage for example, refactored
09:33:45 <JeniT> timbl: is it horribly cumbersome to do that?
09:34:04 <JeniT> marcosc: it's nice. The XHR example is very easy to understand
09:34:09 <JeniT> ... integrating with events too
09:34:19 <JeniT> timbl: you mean the developer is using events as well?
09:34:41 <JeniT> marcosc: you can remodel the same thing to hook into the events, and use the promises you create to give an API that's very simple to use
09:34:46 <JeniT> ... showing that is 20 lines of code and very useful
09:35:04 <JeniT> ht: that's a very high leverage way of engaging the web community
09:35:14 <JeniT> plinss: do we have consensus?
09:35:27 <JeniT> [yeses]
09:35:54 <JeniT> .RESOLUTION: The TAG supports Promises and will help drive their adoption throughout the platform
09:36:33 <JeniT> JeniT: what are the arguments against?
09:36:47 <JeniT> wycats_: one argument is the monadic promises thing
09:36:57 <JeniT> ... which I think we can leave TC39 to argue
09:37:19 <JeniT> ... the argument that is more relevant is from Node.js
09:37:36 <JeniT> ... they coordinated around error-first callbacks
09:37:43 <JeniT> ... where errors are called as the first parameter
09:37:53 <JeniT> slightlyoff: those are nicer in some ways
09:38:22 <JeniT> ... by presenting the error as the first argument, the fact there might be an error is emphasised
09:38:35 <JeniT> timbl: I standardised on that because I was losing too many errors
09:39:05 <JeniT> wycats_: if you choose to use that pattern, you'll handle the error
09:39:15 <JeniT> slightlyoff: we can evolve Promises to do error-first callback
09:39:35 <JeniT> wycats_: error-first callbacks don't separate the call from the eventual value
09:39:42 <JeniT> ... so it's hard to build abstractions around it
09:40:19 <JeniT> ... you have to use all() around a bunch of functions
09:40:25 <JeniT> ... it's hard to do combinations
09:40:52 <JeniT> annevk: the concern I've heard the most is completely different, that they're not stable yet
09:41:11 <wycats_> I wouldn't say it's hard, but it's hard to package up a bunch of eventual values and do abstractions around them
09:41:16 <JeniT> slightlyoff: yes, there's disbelief and unfamiliarity
09:41:45 <JeniT> wycats_: many people using Node.js use libraries that use Promises
09:41:51 <JeniT> timbl: the TAG can show the adoption path
09:42:04 <JeniT> ... to show that new libraries can support old code
09:42:17 <JeniT> ... demonstrate there's only benefit in supporting promises
09:42:26 <JeniT> ... push it to libraries, then to developers
09:42:33 <JeniT> noah: are they actively pushing back?
09:42:40 <JeniT> wycats_: they can't avoid adopting, because they use V8
09:43:11 <JeniT> annevk: there are two conversations, one around the platform APIs and one around error-first callback
09:43:19 <JeniT> noah: we have to coordinate across W3C and others
09:43:28 <wycats_> https://npmjs.org/package/q
09:43:34 <wycats_> 322 dependents
09:43:37 <JeniT> ... Node.js has expertise in dealing with async stuff, and they're objecting
09:43:45 <JeniT> ... are they worried about object creation overhead?
09:43:52 <JeniT> wycats_: I haven't heard them bringing up performance
09:44:00 <JeniT> slightlyoff: you're already creating objects, in either model
09:44:14 <JeniT> ... the Node.js community doesn't have the same latency issue as a game developer
09:44:28 <dka_> A refinement of the proposed .RESOLUTION: The TAG supports the continued development of the work on Promises, including helping to drive their adoption, socialisation of the work with more communities, and the continued refinement of the concept…
09:44:41 <JeniT> noah: if the TAG is coming close to making a resolution, we should reach out to that community
09:45:25 <JeniT> wycats_: even if it doesn't solve Node.js's problems, it solves platform API's problems
09:45:40 <JeniT> slightlyoff: the Node.js community isn't our community
09:45:51 <JeniT> ... it's divorced itself from standard web APIs in several cases
09:46:05 <JeniT> ... for example inventing a module system diverting from ES6
09:46:44 <ht> q+ to suggest a workshop
09:46:52 <JeniT> timbl: can I propose we wrap-up Futures/Promises, and queue as an agenda item the relationship between Node.js and the platform
09:47:02 <JeniT> wycats_: the Node
09:47:14 <JeniT> s/wycats_: the Node//
09:47:32 <JeniT> dka_: I suggested a clarification to the resolution wording
09:48:05 <wycats_> the node community believes that constant API churn is bad for their ecosystem, and therefore do not want to adopt ecosystem-wide paradigm changes if their solutions are working
09:48:22 <JeniT> .RESOLUTION: The TAG supports the continued development of the work on Promises, including helping to drive their adoption, socialisation of the work with more communities, and the deployment and development of the concept
09:48:43 <wycats_> they have developed node during a period of extraordinary language stability, and they are going to have to grapple with more language change eventually, beyond just promises
09:48:50 <JeniT> timbl: the message is that we have consensus between Ecmascript and the platform, and that's big enough to say we're not going anywhere else
09:49:14 <JeniT> Yves: is it too early to write a document?
09:49:15 <JeniT> wycats_: no
09:50:18 <JeniT> .RESOLUTION: The TAG supports the work on Promises, including helping to drive their adoption, socialisation with more communities, and the deployment and development of the concept
09:50:27 <JeniT> RESOLUTION: The TAG supports the work on Promises, including helping to drive their adoption, socialisation with more communities, and the deployment and development of the concept
09:50:36 <JeniT> ht: I wonder if we should try for a W3C workshop of this
09:50:42 <JeniT> s/of/on/
09:51:05 <JeniT> [BREAK for 20 mins]
09:53:10 <JeniT> JeniT has joined #tagmem
10:11:02 <dka_> dka_ has joined #tagmem
10:19:39 <dka_> q?
10:19:42 <dka_> ack ht
10:19:42 <Zakim> ht, you wanted to suggest a workshop
10:19:48 <JeniT> [BACK]
10:20:06 <JeniT> ht: we should have a workshop on the larger topic of platform API stakeholder consistency
10:20:10 <JeniT> marcosc: primitives
10:20:13 <JeniT> Yves: something at TPAC?
10:20:16 <JeniT> ht: possibly
10:20:39 <JeniT> ... W3C workshops are another tool that we could employ
10:20:56 <JeniT> wycats_: the process of workshops aren't familiar or helpful for web developers
10:21:04 <JeniT> ... particularly requiring position papers
10:21:13 <JeniT> ht: it's possible to have workshops without requiring position papers
10:21:33 <JeniT> noah: was the meeting a waste of time?
10:21:49 <JeniT> wycats_: it ended up meaning the workshop didn't contain developers, which made it less useful
10:22:05 <JeniT> slightlyoff: there were meetings last year that I participated in
10:22:13 <JeniT> ... an invited group of people
10:22:33 <JeniT> ... that and W3C workshop have similarities and impact
10:22:41 <JeniT> ... the difference in style gives different outcomes
10:22:47 <JeniT> wycats_: you're too charitable
10:23:03 <JeniT> ... at the workshop and developers at the Offline workshop
10:23:19 <JeniT> ... the developers & annevk & darobin removed ourselves from the workshop
10:23:37 <JeniT> ... the predefined structure of the workshop didn't work
10:23:51 <JeniT> dka_: in defence of workshops
10:24:01 <JeniT> ... I understand the issues, but part of the point is to try to be an open forum
10:24:15 <JeniT> ... what Alex described is a bunch of people who know each other
10:24:36 <JeniT> ... the whole idea of the W3C workshop process is to announce publicly that it's going to happen
10:24:38 <noah> q?
10:24:45 <JeniT> ... to try to get people in the room who aren't talking to each other already
10:24:56 <JeniT> ... and the point of the position papers is to eliminate kooks
10:25:03 <JeniT> ... you have to have something coherent to say
10:25:12 <JeniT> wycats_: the people who wrote position papers were kooks
10:25:42 <JeniT> timbl: philosophically, if you want to get people together you have to find a way of doing it
10:25:49 <JeniT> ... we found too many people coming to workshops
10:26:03 <JeniT> ... we found that asking for a small paragraph in email as a position paper set a bar
10:26:23 <JeniT> ... later as things got bigger we found that we needed a programme committee
10:26:36 <JeniT> ... workshops shouldn't turn into conferences
10:26:42 <JeniT> ... think of a way of getting the right people in the room
10:27:07 <JeniT> wycats_: I was invited but I wasn't able to speak
10:27:14 <JeniT> marcosc: it was an unconference!
10:27:25 <JeniT> wycats_: most of the people there weren't familiar with the actual problem
10:27:49 <JeniT> dka_: let's discuss this over lunch
10:27:59 <JeniT> wycats_: we have to discuss this before I'm happy with a workshop
10:28:15 <JeniT> Yves: this is why I suggested TPAC because you can present to a larger amount of people
10:28:26 <JeniT> noah: you're over thinking this
10:28:37 <darobin> [more precisely, most of the people there were familiar with the *use case* problems — i.e. that they couldn't deliver — but weren't familiar with the actual technical problem]
10:28:45 <Yves> and more generally WG that would need to hear about such topic
10:28:47 <JeniT> ... if a workshop is potentially promising, make it someone's responsibility to organise it
10:29:20 <JeniT> ... asking people to write stuff in advance is a good thing because it helps people think about what they want to say
10:29:28 <annevk> Basically, we should have a barcamp around the web platform. Workshops / conferences are a pain.
10:29:32 <JeniT> ... put it together in an appropriate way for getting the people you want in the room
10:29:52 <JeniT> dka_: I was one of the chairs of the Offline workshop, so I want to know about what was wrong about it
10:29:57 <JeniT> ... for this topic, we can move on
10:30:14 <JeniT> Topic: Streams
10:30:51 <JeniT> annevk: we don't know enough about this to talk now
10:31:06 <JeniT> Topic: TAG operations
10:31:37 <JeniT> dka_: we've talked about enough content to be able to ground this discussion about how we operate
10:32:02 <JeniT> plinss: the one thing on Promises to tidy up is a next action
10:32:31 <JeniT> dka_: marcosc, you gave a briefing to the SysApps WG about how to operate, I was wondering how much of that we could adopt
10:33:16 <JeniT> marcosc: there's what I did with SysApps, and what slightlyoff, wycats_ & annevk have done with private repos that they've then opened up
10:33:31 <JeniT> ... we have a github organisation & repo that JeniT's already used for her slides
10:33:42 <JeniT> ... it's easier in some respects than CVS
10:33:57 <JeniT> ... on the other hand there's lots of infrastructure currently in place for the TAG
10:34:05 <JeniT> ... like generating minutes etc it's super useful
10:34:06 <annevk> https://github.com/w3ctag/ exists
10:34:25 <JeniT> dka_: how we use github and moving things over to github is one key topic
10:34:50 <JeniT> annevk: we have a github organisation already
10:35:26 <JeniT> noah: the main things that we've gotten from CVS from the past decade is instantaneous path to publication in W3C space, with ability to maintain long term persistence
10:35:36 <JeniT> ... sometimes that's useful to get coverage with IP rules
10:35:56 <annevk> Btw, if people can give me their usernames I will add them
10:35:58 <JeniT> ... I've been told that some WGs have cloned repos into W3C space, but I don't know about the control over URIs
10:36:06 <annevk> Yves, plinss, dka_, ht, timbl?
10:36:32 <JeniT> timbl: github does not naturally allow you to host a website, it doesn't give you control over mime types
10:36:47 <JeniT> wycats_: you can manage those within github
10:37:21 <JeniT> ht: what's wrong with CVS? it's not broken
10:37:31 <JeniT> wycats_: other people who don't have CVS access can't collaborate with you
10:37:56 <JeniT> ht: if we have projects that need collaboration, fine, but we don't always need collaboration
10:38:26 <JeniT> ... can't we use CVS for most of our work, and use github when we want to collaborate
10:38:45 <JeniT> timbl: Henry's concerned about public write access
10:38:55 <JeniT> wycats_: github doesn't give public write access
10:39:20 <JeniT> dka_: this is why I asked marcosc to introduce the topic from the perspective of other WGs
10:39:34 <JeniT> ... then we can talk about how we mix this approach with the existing W3C approach to get the best of both worlds
10:39:38 <JeniT> ... this isn't an either/or
10:39:53 <JeniT> noah: my question was about what control you get over URIs
10:40:29 <JeniT> marcosc: currently, W3C has a htaccess file that redirects from W3C space to github space
10:40:44 <JeniT> noah: is it easy to make multiple URIs and include dates in URIs?
10:41:11 <JeniT> marcosc: yes
10:41:24 <JeniT> wycats_: there's a huge gap in understanding about how github works here
10:41:46 <JeniT> dka_: noah, you're conflating how we are doing it and how we should do it
10:42:25 <JeniT> noah: we've needed dated versions so that we can discuss drafts in meetings and having a dated version referenced from the minutes
10:42:56 <JeniT> marcosc: when you check something in, you can see diffs for changes
10:43:26 <JeniT> wycats_: you can do everything you want to do with tooling on top of gh-pages
10:44:06 <JeniT> noah: when the URIs are mirrored from W3C space, do you get stability?
10:45:00 <JeniT> ... what happens if/when github blows up?
10:45:17 <JeniT> wycats_: we can move the network storage and get the URI persistence
10:45:37 <JeniT> timbl: I like github in lots of ways, pull requests, a lot of stuff on top of git
10:45:56 <JeniT> ... what W3C gives you is persistence for history, so you can go back and check
10:45:59 <JeniT> ... we have the CVS record
10:46:10 <JeniT> ... we can see what happened, who changed things etc
10:46:18 <JeniT> ... at the moment all that is within w3.org
10:46:25 <JeniT> ... we have comma tools and so on
10:46:33 <JeniT> wycats_: why don't we have that with github?
10:46:45 <JeniT> timbl: W3C has a persistence guarantee
10:46:54 <JeniT> annevk: you can clone the git
10:47:08 <JeniT> timbl: we could every night sync onto w3c space
10:47:13 <JeniT> dka_: including the commit history
10:47:33 <JeniT> timbl: the problem is that if you use the github tools like issues etc then it doesn't include that history
10:47:49 <JeniT> ... anything that's decentralised, I'm happy to use whatever tools we like
10:48:00 <JeniT> ... I'm worried about tracker, the messaging
10:48:08 <JeniT> wycats_: the pull request feature is the most problematic part
10:48:34 <JeniT> plinss: the CSS WG mirrors our repositories onto github
10:48:41 <JeniT> ... we don't use issue trackers
10:48:51 <JeniT> ... our test suites and our drafts are on github
10:49:00 <JeniT> ... the canonical source is Mercurial on W3C space
10:49:22 <JeniT> ... we have git and hg versions of both repos
10:49:27 <JeniT> ... I'd propose we do the same thing
10:49:53 <JeniT> ... using the github collaboration for pull requests and so on
10:50:02 <JeniT> ... github have APIs for those
10:50:16 <annevk> Everyone should be added to the owners of the w3ctag thing now except for ht. Could not find ht on GitHub.
10:50:17 <JeniT> ... we can use those to pull out that data
10:50:39 <ht> I should be there. . .
10:50:41 <ht> Hang on
10:50:47 <JeniT> ... I'm syncing all the issues etc for 'Shepherd' from github
10:51:21 <JeniT> timbl: I'd love to see the issues etc be written out into a standard format
10:51:34 <JeniT> plinss: we can capture all that data and keep our own archive of it
10:51:48 <JeniT> ... I like the social part of github, I'm not comfortable to rely on them for our storage
10:52:00 <JeniT> dka_: the question I asked was about what happens when HP buys github
10:52:05 <JeniT> ... we need to have a story for that
10:52:13 <RRSAgent> I'm logging.  Sorry, nothing found for 'log'
10:52:17 <JeniT> plinss: we can't rely on that
10:52:24 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/30-tagmem-minutes.html Yves
10:52:34 <JeniT> annevk: the most important information is in the repo, not the issue tracker
10:52:45 <JeniT> ... the issue tracker should be a thing you can use
10:52:48 <JeniT> s/use/lose/
10:53:06 <JeniT> timbl: issue tracker history is interesting
10:53:25 <JeniT> noah: one of the things to watch about the TAG is how long it runs relative to how quickly its membership turns over
10:53:38 <JeniT> ... the TAG has a long term presence, and the same issues come up after 8/10 years
10:54:03 <JeniT> ... some combination of minutes/action etc needs to be captured
10:54:15 <JeniT> timbl: CSS predates the TAG
10:54:32 <JeniT> dka_: Yehuda, you started to articulate a story about this
10:55:14 <JeniT> wycats_: when whytheluckystiff nuked himself, people managed to reconstruct almost all his work through local copies
10:55:45 <annevk> noah, do you have GitHub account, and if so, should I add you to the repo?
10:55:54 <annevk> (everyone else is added)
10:55:55 <JeniT> ... you tend to be able to reconstruct content
10:56:11 <JeniT> timbl: how do people feel about using Google Docs?
10:56:51 <JeniT> dka_: I'd use it for an agenda for example, but not for anything else
10:57:23 <JeniT> timbl: Google has a reputation for being one big company and people feel uncomfortable about it, whereas people think of github as one big space when actually they're a company too
10:58:29 <JeniT> ... people think of large companies with a monopoly, like github, as being problematic because of putting all their eggs in one basket
10:58:47 <darobin> darobin has joined #tagmem
10:58:47 <JeniT> dka_: I think it makes sense to mirror what the CSS WG is doing, to make sure we mirror content
10:58:59 <JeniT> ... I expect W3C to be around in 50 years
10:59:24 <JeniT> noah: are you saying that documents should be referenced through w3.org?
10:59:26 <JeniT> dka_: yes
10:59:50 <JeniT> noah: you're taking the gamble that w3c will make the investment of rescuing stuff to rehost our stuff that's in github
10:59:57 <JeniT> dka_: it'll already be done because it'll be a clone
11:00:11 <JeniT> noah: github has a collaborative model, whereas W3C work has IP commitments
11:00:26 <JeniT> ... we expect email without IP commitments, for example
11:00:43 <JeniT> ... but core work needs to be under those commitments
11:01:04 <JeniT> wycats_: you need a click-through CLA (usually hosted by Google forms) and you don't accept pull requests without people having completing that
11:01:28 <JeniT> marcosc: in github you can have a contributing file that requires you to agree before committing
11:01:30 <darobin> [I'd like to suggest that maybe using the w3c organisation on GH might work better than creating a new one as we expect that it will get automatically hooked up with e.g. sync to W3C site and such]
11:01:48 <JeniT> plinss: in the test suite repos, the click-through you have to sign is a W3C form
11:01:56 <JeniT> ... and the counsels are ok with that
11:02:17 <JeniT> ... before you accept a pull request, you have to check that people have signed it
11:02:26 <JeniT> noah: so you have to do some manual due diligence
11:02:47 <JeniT> dka_: that's true anyway, if people post to W3C mailing list
11:03:03 <wycats_> try curl https://api.github.com/repos/wycats/handlebars.js/pulls
11:03:07 <JeniT> Yves: before you can post to the mailing lists, you have to agree to IP commitments
11:03:14 <JeniT> ... we can have the same thing for pull requests
11:03:45 <JeniT> ht: I'm more familiar with Mercurial than github
11:03:58 <JeniT> ... it's good for me if I can use Mercurial
11:04:03 <wycats_> http://hg-git.github.io/
11:04:08 <annevk> http://www.w3.org/2002/09/aa/ does not say anything about licenses Yves
11:04:27 <JeniT> ... I'm not sure that I've heard about how things get auto-published to W3C space
11:04:39 <Yves> hum, I'm pretty sure there was something for contributed text, I'll check
11:05:05 <darobin> [also see http://www.clahub.com/]
11:05:07 <JeniT> ... if I want to create a document in W3C space today, I can use CVS and just commit it in and it appears
11:05:21 <JeniT> annevk: we can do that too, with a commit hook
11:05:37 <annevk> we would really
11:05:38 <JeniT> timbl: can you make a commit hook on github to ping somewhere else?
11:06:00 <JeniT> wycats_: yes, you can receive anything that happens on a repo
11:06:12 <JeniT> timbl: we'd like a piece of W3C space that is automatically synced
11:06:23 <JeniT> plinss: we're doing that in CSS WG
11:06:33 <darobin> [we use hooks extensively to publish the web-platform-test to w3c-test.org, to push ReSpec releases to w3.org, etc.]
11:07:01 <JeniT> timbl: one of the things I like about W3C is that the basic URI is the thing that everyone sees
11:07:09 <JeniT> ... you've got ,cvs, ,log etc
11:07:24 <JeniT> ... encrusted URIs for views of the repository, but the pure URI is the clean URI
11:07:41 <JeniT> ... in github the default URI is the under-the-covers URI
11:07:49 <JeniT> plinss: we can set up both views
11:08:04 <JeniT> ... we can add the comma operators
11:08:11 <JeniT> timbl: we can do that in the htaccess, yes
11:08:28 <JeniT> plinss: we can have all of what we have with CVS with a git and mercurial system
11:08:35 <JeniT> ... it takes a little bit of glue but we can do it
11:08:47 <JeniT> timbl: people will end up referring to the github version
11:08:55 <noah> I thought Yehuda said: "Published spec XXX says MUST" which one?
11:09:03 <dka_> q?
11:09:06 <JeniT> plinss: some of the WGs live around the hg repos
11:09:13 <noah> By the way, updated F2F agenda with correct time slots for what we actually discussed is checked in at http://www.w3.org/2001/tag/2013/05/29-agenda.html
11:09:17 <JeniT> ... in CSS we're very careful to use the w3.org URIs
11:09:26 <JeniT> ... we'll have to do the same thing here
11:09:41 <JeniT> marcosc: in an ideal world, all this stuff would work, I don't think it's difficult to get this sorted
11:09:56 <noah> q+ to say when github discussion dies down, I'd like to briefly ask about product pages and how you'd like to goals, deliverables, dates, etc. for ongoing projects
11:09:58 <annevk> (git syncing is being worked on by systeam)
11:10:23 <JeniT> ... what I'd like to see some day is that the stuff that Alex & Yehuda have been working on in their private repos should be in the w3ctag organisation
11:10:29 <JeniT> wycats_: I'm happy to do that
11:10:41 <dka_> q?
11:10:59 <JeniT> annevk: I've added people except noah
11:11:05 <JeniT> noah: I need to get a userid on github
11:11:35 <JeniT> marcosc: when stuff starts happening on github, they can follow repos etc
11:11:43 <JeniT> ... we don't have a paid account
11:11:54 <JeniT> ... so can't have a private repo
11:12:10 <JeniT> ... we need to sort out some logistics to manage that
11:12:18 <JeniT> dka_: for each piece of work we have a repo
11:12:29 <JeniT> ... there's work to be done in writing these scripts
11:12:32 <JeniT> plinss: I'll do that
11:12:41 <JeniT> annevk: I have scripts for the WhatWG specs
11:13:25 <JeniT> plinss: one more thing, we could be using the w3c organisation rather than w3ctag
11:13:57 <JeniT> annevk: I discussed with darobin, but it's easier this way because we can create repos as we like
11:14:25 <JeniT> dka_: can we get W3C to pay for the repo?
11:14:32 <JeniT> annevk: WhatWG got it for free
11:14:37 <JeniT> dka_: so we can pull rank?
11:14:46 <JeniT> annevk: if you email them you can get it
11:15:05 <JeniT> marcosc: we already have people who are paying members
11:15:13 <JeniT> annevk: shall I email them?
11:15:18 <JeniT> dka_: yes
11:15:20 <dka_> q?
11:15:38 <JeniT> ... noah has a corollary issue about product pages
11:16:15 <JeniT> noah: when I came in as chair, we weren't tracking the goals of what we were doing, who's doing it, what the checkpoints are
11:16:24 <JeniT> ... my answer to that was HTML pages
11:16:34 <JeniT> ... because the tools weren't flexible enough for anything else
11:16:44 <JeniT> ... and then we have a roll-up page which is like a dashboard for the TAG
11:16:59 <darobin> [note that w3c already has access to private repos, so you can reuse that if needed]
11:17:34 <JeniT> ... this is for helping to keep track of the goals and focusing discussion
11:17:55 <JeniT> ... I don't care how you do it, but do you want to keep track of these kinds of long term goals, like the Promises work
11:18:06 <JeniT> wycats_: is the infrastructure in the repo sufficient?
11:18:25 <JeniT> noah: it doesn't give the community information about the goals
11:18:37 <JeniT> dka_: we could use a README file
11:18:42 <JeniT> ... in the repo
11:18:52 <JeniT> timbl: all those documents can be stored in a repo
11:19:14 <JeniT> wycats_: README is special in github, it's rendered and displayed in the repo
11:19:33 <JeniT> noah: it's useful having a dashboard page
11:19:51 <JeniT> JeniT: the list of repos gives a dashboard
11:19:56 <JeniT> noah: needs to be accessible to AC members
11:20:41 <dka_> ack noah
11:20:41 <Zakim> noah, you wanted to say when github discussion dies down, I'd like to briefly ask about product pages and how you'd like to goals, deliverables, dates, etc. for ongoing projects
11:20:59 <JeniT> JeniT: we need some social conventions about what needs to go in the READMEs for those to work
11:21:18 <JeniT> noah: I tried not to let tools be an excuse for doing a crappy job
11:22:14 <JeniT> dka_: we've only talked about incorporating github into our operations
11:22:20 <JeniT> ... we haven't talked about minutes for example
11:22:33 <JeniT> ... plinss and I have discussed that automatic minute taking is extremely useful
11:22:42 <wycats_> fwiw: https://github.com/rwldrn/tc39-notes
11:22:53 <wycats_> for example: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-05/may-21.md
11:22:56 <JeniT> ht: we already have a two-track story about that
11:23:06 <JeniT> ... the vanilla minutes come out in W3C date space
11:23:16 <JeniT> ... the cleaned up approved minutes go into TAG space
11:23:26 <JeniT> ... that step could move into git-managed TAG space
11:23:30 <JeniT> ... if we're ready to do that
11:23:31 <wycats_> actually they've gotten better: https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-03/mar-12.md
11:23:54 <JeniT> noah: with CVS we can do a grep over 10 years of minutes
11:24:04 <JeniT> plinss: we can take a copy of the older minutes
11:24:08 <JeniT> ... we can map the URIs
11:24:48 <JeniT> dka_: we need to figure out how we do that
11:24:59 <JeniT> ... personally I'd like to see minute taking and cleanup be easier than it has been
11:25:14 <JeniT> ... it felt difficult to clean up minutes when I was in the TAG
11:25:33 <JeniT> ht: it's a pain but it's worth it
11:25:45 <JeniT> dka_: the mechanics are hard, not the intellectual effort
11:25:57 <JeniT> noah: linking imagines in the minutes are helpful
11:26:19 <JeniT> Yves: it should be easy to import CVS history into github
11:26:27 <JeniT> noah: how do you want this round of minutes done?
11:26:35 <JeniT> dka_: as we have been
11:26:39 <JeniT> plinss: we're not changing things now
11:26:49 <JeniT> dka_: we're going to have Siri auto-generate them
11:27:01 <JeniT> plinss: we've talked about using github
11:27:08 <JeniT> ... we also have the TAG blog, wiki and twitter account
11:27:12 <JeniT> ... we need to be using these tools too
11:27:22 <JeniT> ... we need to categorise when we use these
11:27:33 <JeniT> wycats_: github is sort of like a wiki
11:27:39 <JeniT> ... you can use it like a wiki
11:28:07 <JeniT> ... you can 'Edit' the READMEs
11:28:28 <JeniT> ... if there's a strong reason not to use github for agendas, fine
11:28:41 <JeniT> slightlyoff: TC39 is moving to using github
11:29:03 <JeniT> dka_: we do have the TAG wiki in W3C space
11:29:17 <JeniT> plinss: there are advantages to using the tools in W3C space
11:29:34 <JeniT> timbl: we've talked about just taking all CVS into git
11:29:50 <noah> scribenick: noah
11:30:35 <noah> tbl: Possible lunch discussion: moving all of W3C Web site to git. Would obviously need to coordinate with systems team.
11:30:49 <noah> tbl: would love to have more flexible way of updating on planes
11:31:01 <noah> pl: OK, but over lunch
11:31:53 <noah> pl: we have a blog
11:32:23 <noah> pl: appropriate to use it for certain things
11:32:32 <noah> pl: quick response, high level overview
11:32:55 <noah> pl: e.g. first crack at futures could be in the blog, or could announce larger docs in the blog, then tweet.
11:34:49 <noah> dka: BREAK for lunch
12:22:46 <marcosc> marcosc has joined #tagmem
12:37:40 <noah> scribenick: noah
12:37:45 <noah> topic: Web Audio
12:38:56 <noah> We are joined in this session by Oliver XXXX from the BBC
12:39:33 <noah> DKA: We are making an effort to reach out to people who are working on important specs. Realizing that you were nearby in London, we wanted to take the opportunity to invite Olivier.
12:40:01 <noah> DKA: This morning we had a discussion of asynchronous programming with futures/promises, so that's one topic that interests us, but an overview of Web Audio would be helpful too.
12:40:29 <noah> OT: I'll update you on two things 1) what the Web Audio group is doing and 2) how it got there.
12:41:15 <noah> OT: The group is hoping to have a "friction" point between the music and Web Audio and game development cultures. There are completely different ways of thinking, even in terms of how you build expect.
12:42:09 <noah> OT: Example, audio processing involves lots of algorithmic. If you've been in the audio processing work, no explanation or specification is needed. Just say you need this or that convolution, and every audio or signal processing engineer knows what you mean. For the Web, we need interop.
12:42:27 <noah> OT: So, there's class about the level of specificity that's most helpful in the specs.
12:43:15 <noah>  HT: I've assumed that the elephant in the room is the huge depolyment of IOS and similar native apps for mixing, sound control, etc. and there's a perception that the Web infrastructure currently can't do it.
12:43:48 <noah> OT: Well, there's a huge history of realtime HW and now SW gear. It's Microsoft as well as Apple, plus custom hardware e.g. for synthesizers, even today.
12:44:43 <noah> OT: We're bringing to the Web an industry that's traditionally depended on massive precision and performance. Occasionally, the problems are more than perception.
12:44:59 <noah> OT: So far, "architectural" decisions have played a small role in the design of the APIs.
12:45:46 <dka_> dka_ has joined #tagmem
12:45:55 <noah> OT: The goal is to provide audio synthesis (e.g. mashing together and process wave files), filters, etc. Another spec is for Web Midi. That's separate. We're talking about midi controllers, not the midi file format. These are used for lighting as well as musical instrument control.
12:46:08 <noah> OT: We are in the process of bridging all those to the Web platform.
12:46:34 <noah> OT: In a way, doing midi in the audio wg is partly an accident, tracing to traditional use of midi for music
12:47:06 <noah> s/XXXX/Thereaux/
12:47:22 <noah> OT: There were attempts to use <audio> tags and Javascript.
12:47:50 <noah> OT: Mozilla had a proposal. Then another proposal was media stream processing, plus one from Google called Web Audio API.
12:48:44 <noah> OT: We chose one proposal with input from the others. Sounds good from outside, but in fact we were stalled for a year on choosing media stream processing and Web audio to choose. Both were perceived as good, but at very different levels.
12:48:58 <noah> OT: The stream option pretty much gave the stream to the Javascript to munge on.
12:49:22 <noah> OT: Had not been fully implemented, but there were partial implementations in Firefox nightlies, etc.
12:50:17 <noah> OT: The Web Audio API came more from music background. The person who built it had a hand in many major developments including Apple Core Audio, IRCAM work, and major plugins for Mac and Windows. he brought that experience to Google.
12:50:55 <noah> OT: So Web Audio lets you combine processing blocks in a graph through which the audio streams are processed. Gives you a framework for composing existing filters.
12:51:18 <noah> DKA: So it's a conceptual model?
12:51:42 <noah> NM: No, it's how people actually build things: get me a block that does reverb and chain it after the block that does EQ.
12:51:46 <noah> OT: Right.
12:51:56 <noah> TBL: Explain again please, what's the difference?
12:52:12 <noah> OT: The streams stuff does less, but is easy to build and ship.
12:52:28 <noah> OT: Javascript libraries would have been built, perhaps using a model like JQuery.
12:53:55 <noah> OT: In the end, the Web Audio API was chosen not entirely on merit. There was discussion of many perspectives.
12:54:05 <noah> YK: What about exposing several levels.
12:54:16 <noah> OT: Thought about it, but there's no clear right answer. This had a lot of buyin.
12:54:20 <noah> MC: Determined how>
12:54:27 <noah> s/how>/how?/
12:54:59 <noah> OT: We got a requirements and use cases out there, and talked to music makers, game developers. Most preferred Web audio. Less work for us and how we think.
12:55:26 <noah> NM: In Web Audio, you can do your own blocks?
12:55:52 <noah> OT: Yes, but it's really complicated almost to the point of being broken. You connect the blocks. There is one generic Javascript blocks.
12:56:22 <noah> NM: You can do your own native blocks or your own Javascript blocks?
12:59:23 <noah> NM: So, in Pro Tools and REAPER etc. there's a huge marketplace of native plugins the compete with each other, e.g. to model a hall or an amp. Is the support of such user-supplied native controls not a major use case for this stuff?
13:00:33 <noah> OT: Um, no.
13:00:37 <noah> NM: I'm surprised.
13:00:48 <noah> AR: Why is there a latency problem with Javascript
13:01:17 <noah> OT: The Javascript version requires large blocks of e.g. 128 samples for the filters to know what to do. The native ones cooperate to avoid the need for that. Not clear on the details.
13:01:25 <noah> AR: Why not do the same thing for the Javascript
13:01:27 <noah> OT: Not sure.
13:01:47 <noah> OT: The supplied building blocks cover 99% of cases. They've been used for years in hardware and software.
13:02:26 <noah> OT: There are still people who complain both that it's too high level and too level. Would love to thing that's a signal we've maybe hit a reasonable compromise.
13:03:00 <noah> OT: There was a proposal to keep what we've got, but add a very simple DSP (add/multiply, maybe fft) that could be used as a building block. Didn't take.
13:03:21 <noah> HT: What about text to speach.
13:03:26 <noah> s/speach/speech/
13:03:43 <noah> OT: Ah, I should have mentioned that most nodes do processing, but some do synthesis.
13:04:24 <noah> HT: Hmm, do we still have the working group doing the phone dialog generation? There's a question of whether you can do text to speech on the device.
13:05:05 <noah> HT: Would be good to verify the necessary hooks are there. I'd say check with the WG, but suspect they're not in business anymore.
13:05:13 <noah> OT: I'm pretty sure you can do text-to-speech
13:06:24 <noah> OT: In summary, we are mostly happily plodding forward, and getting everyone (aside from one big actor) to implement it. Mostly, users are very happy with it. Every 6 months or so we trip over questions of whether latency is OK and whether the level is right. We don't seem to find good alternatives.
13:07:28 <noah> OT: In terms of TAG issues, my story may be frustrating. It's not clear we've cracked the "what's the right level?" question. We've let the market decide.
13:08:10 <noah> YK: I've heard similar stories from other groups, I.e. couldn't choose the right level, so we had to pick one. You'd think about layering.
13:08:47 <noah> OT: There's a cost to that layering. You can't optimize across.
13:10:27 <noah> NM: Let's keep in mind that these folks are struggling to meet latency requirements. There are some really cool CS papers from years ago saying "a layered design is not a justification for a layered implementation" if maximum performance is needed.
13:11:26 <noah> See Watson and Mamrak, Gaining efficiency in transport services by appropriate design and implementation choices dl.acm.org/citation.cfm?id=13677.13678
13:11:50 <noah> YK: Transferrables help
13:12:10 <noah> AR: It's really good if the APIs feel like natural Javascript APIs, even if the implementation is native, tricky, and highly optimized
13:12:53 <noah> AR: It also let's people do test implementations in Javascript.
13:13:32 <noah> YK: It feels like the HTML <audio> tag could be described in terms of the API that you have, and it seems that might be beneficial.
13:13:35 <noah> OT: Yes
13:13:49 <noah> AR: Does scrubbing work?
13:14:01 <noah> OT: Yes, just start playing the middle of a buffer
13:14:09 <noah> MC: The <audio> tag is mentioned in the spec?
13:14:18 <noah> Someone: as source or target
13:14:20 <noah> MC: Hmm
13:14:58 <noah> AR: Reads details of the way you create a source from element and points out many shortcomings. Would be nice to just plug a graph into an <audio> element.
13:15:09 <noah> AR: ...and video. There are real benefits.
13:15:13 <noah> OT: That makes some sense.
13:15:37 <noah> YK: Would tend to make it more composable with <video> tag, WEB RTC, etc.
13:16:23 <noah> AR: The <audio> element is owned by the HTML WG, and has an API. I >think< this could be desugared into the Audio API?
13:16:31 <noah> YK: You probably should do for more of them.
13:17:08 <noah> MC: Section 20 speaks of required support for alternative names. Forces support of same feature under multiple names. This seems to set really bad precedent. What led to this? Why is it there?
13:17:46 <noah> OT: We've had implementations being used as a platform for > 1 year using old names, albeit behind a prefix. Group decided let's deprecate them.
13:17:57 <noah> AVK: Clarify, the prefix is only on the constructor.
13:18:41 <noah> YK: The general way the platform deals with this is not to standardize the non-standard forms.
13:18:45 <noah> We are discussing: http://www.w3.org/TR/webaudio/#deprecation-section
13:19:06 <noah> Lots of pro/con discussion of how bad this really is and what the precedents are
13:19:38 <noah> MC: I was confused and annoyed.
13:20:27 <noah> OT: You're actually showing why, in practice, there's a lot of documentation out there we can't recall. We can deprecate it and ask everyone to stop using it. Or we can deal with it by saying there are synonyms.
13:20:47 <noah> MC: It adds to surface area of API>
13:24:50 <noah> NM: We've heard from OT that the group really felt they needed to keep the old duplicate names.
13:25:00 <Zakim> Zakim has left #tagmem
13:25:04 <noah> OT: Indeed, we tried dropping them and 5 mins later the complaints had convinced us to change.
13:25:38 <dka_> trackbot, start meeting
13:25:40 <trackbot> RRSAgent, make logs public
13:25:40 <Zakim> Zakim has joined #tagmem
13:25:42 <trackbot> Zakim, this will be TAG
13:25:42 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
13:25:43 <trackbot> Meeting: Technical Architecture Group Teleconference
13:25:43 <trackbot> Date: 30 May 2013
13:25:54 <dka_> q?
13:25:58 <noah> NM: I'd like to suggest that the TAG be someone open to such feedback that points in directions we don't think we like. I have no idea what the right answer is on this one, but we're hearing from real users who've worked hard that they decided not to deprecate. We should have some humility in listening to perspectives that surprise us.
13:26:43 <noah> OT: We at first thought supporting all of it would be really painful, now we're seeing it as not so painful.
13:26:52 <noah> YK: OK, but why standardize it?
13:27:48 <noah> PL: Exactly. Consider CSS linear gradient. The standard is going to do it this way. We fully understand that many implementations will additionally support the old way, but crucially, we will not support implementors of new systems without installed base to include the old stuff.
13:28:02 <noah> OT: In our case, it's only the names that are different.
13:28:09 <noah> PL: We have exactly the same thing in CSS
13:28:38 <noah> OT: Do you keep an informal reference
13:28:44 <noah> PL: Maybe a non-normative note
13:29:14 <noah> AR: Maybe you can prove to yourself someday to drop it.
13:29:21 <noah> TBL: Do you warn or deprecate?
13:29:24 <noah> AR: Sometimes
13:29:42 <noah> AR: Leaving it in the spec increases use
13:30:44 <noah> NM: Yesterday we heard that as things evolve from experimental to production, the function changes. This is a counter-example.
13:32:15 <noah> AR: This is very different, because this was all under the control of one working group. Yesterday we were talking about experimental stuff being hacked on by the community before the standards process even cranked up.
13:32:51 <noah> OT: I'm not remembering why support for these was required rather than allowed. >Might< have been the Mozilla rep saying they would be at unfair disadvantage to not have it in the spec.
13:33:44 <noah> AVK: I suspect Mozilla felt that if the Web depends on it, it should be documented.
13:34:14 <noah> HT: The question of which legacy matters most is clearly on the table. If there's a bunch of content that uses this, and new implementations don't support it, you've broken the Web.
13:35:14 <noah> YK: The percentages of the Web we're talking about here.
13:36:32 <noah> MC: The audio specification describes what's in Webkit. The question is how the content got into the Web.
13:36:44 <noah> YK: We should have an agenda item.
13:38:16 <noah> OT: The interesting thing is that we used prefixes and it didn't help.
13:38:25 <noah> HT: As it didn't for x- media types
13:38:55 <noah> NM: So, I remain a bit suspicious that the story we heard yesterday that uses hyphenated names might also prove to lead to problems.
13:39:04 <noah> AR: I think it's different, because it comes from user code.
13:39:14 <dka_> q?
13:39:22 <noah> NM: You may well be right Alex, it just reminds me of a pattern that seems to often not work as well as one hopes
13:40:24 <noah> OT: We felt there was a bit of pain in the spec, and very little for platform implementors. If you as the TAG have evidence it's going to be really painful in the long run, that's useful input. It would be good to have "proof".
13:40:56 <noah> HT: Yes, if we were to formally disagree, we would have to back that with evidence
13:41:36 <noah> HT: If I were a WG member I'd be sitting here saying "I think I have good reason for this". Having the TAG say "don't do that" wouldn't help. Reasons would help.
13:41:50 <noah> AR: You could make it non-normative without affecting implementors at all.
13:42:07 <noah> AR: Eventually, market developments could lead to removal.
13:42:25 <noah> AR: It's also not clear early adoption is sufficient to be worth preserving the compatibility
13:43:09 <noah> HT: Possible proposal from the TAG: "Move them to non-normative appendix, acknowledging that it's a change"
13:43:09 <slightlyoff> noah: yes
13:43:32 <noah> OT: What if someone follows only normative spec, they find they don't support some apps.
13:45:00 <ht> So this calls AR's 2nd point into question, i.e. that there is a level of breakage below which the cost is acceptable.  If vendors see _any_ "your browser is broken" threads running on slashdot, they will be furious
13:45:30 <slightlyoff> ht: you can't prevent those
13:45:37 <slightlyoff> ht: they happen
13:46:54 <noah> NM: You can put in the appendix an explanation that if you want to support applications  that were written to the old experimental API, you need to implement the non-normative appendix. Your product manager can make the choice whether that's worth the cost.
13:47:06 <noah> DKA: I'd like to limit the discussions to issues around audio.
13:47:25 <noah> HT: I made a proposal. I'd like to either develop wording for a proposal, or punt.
13:47:36 <noah> YK: I'd like to put an agenda item up for another time to discuss the general problem.
13:47:47 <noah> AR: I think there are several other related things worth discussing.
13:47:56 <noah> HT: Having the concrete example has been helpful.
13:48:28 <noah> AR: There are a set of specific issues as to whether the APIs are idiomatic, connections to html elements, etc.
13:48:42 <noah> ??: Are you the person with whom to speak (laughter)
13:49:20 <JeniT> s/??/YK/
13:49:28 <noah> OT: Yes, but even better is to address the whole group directly. I am just a little worried that you're reopening what stalled us for a year. If need be, do it, but...
13:49:37 <noah> OT: Do it early rather than late.
13:50:37 <noah> TBL: By, it's been out there a long time do people mean you've been at it in the group for a long.
13:51:05 <noah> OT: No, it's been in Webkit for a year and people have been using it. Now there's this emotional argument of "people are using it, don't hurt them"
13:52:39 <noah> MC: Well, this feels less like the TAG's story. We're looking for a clean, orthogonal Web.
13:53:10 <noah> NM: I think that oversimplifies the role of the TAG. If there's a good reason for the Web to be messy in spots, the TAG should help everyone understand where and why, and how to do it to minimize the damage.
13:53:41 <noah> PL: CSS has a lot of experience with related issues. We put a lot of energy into minimizing changes that prefixed things leak out into production builds.
13:54:07 <timbl> "This page best viewed with … the developer mode on"
13:55:20 <noah> NM: I'm not 100% convinced this is the same. CSS is down to building stuff that's often nice to have, not required. These folks are trying to get the world to believe the Web can do audio. Requiring download of an experimental browser for users to try that has costs.
13:55:30 <noah> PL: Yes. There's no one right answer for all scenarios.
13:55:59 <noah> AR: I'm hoping WGs are attempting to be data-driven. In Webkit etc we could get usage histograms.
13:56:20 <noah> OT: We have such data, and do drop things with low use. It's all relative. We have 100s where CSS has millions.
13:56:51 <noah> DKA: About to take a break
13:57:30 <noah> YK: One last point. As a Web developer who uses experimental features, things break all the time. In the developer community, we expect a pre-standards come with no guarantees.
13:58:48 <noah> OT: I agree with 99% of what you say, but there's more question about what people think is a standard. There are people who think Web Audio is a standard.
13:59:03 <noah> YK: Everyone knew 2 years ago it was broken
13:59:15 <noah> OT: But lately it's perceived as a standard
14:02:09 <noah> NM: So, this is all about supporting people who developed their stuff in just a few months? That's the only community who would be impacted? Gee, it sure seems like making it informative and for supporting that bit of experimental development isn't convincing.
14:02:30 <noah> OT: Well, I personally am not hard over that it be normative. Maybe we could bring that back to the group.
14:02:41 <noah> MC: That would be good, as we're worried about precedent.
14:03:03 <noah> DKA: Thank you so much for coming. Having you here in person is very helpful and very much appreciated.
14:03:16 <noah> YK: I don't think we're advocating for breaking existing standards.
14:03:31 <dka_> q?
14:04:06 <noah> PL: One of the things we're trying to do with the reconstituted TAG is to do emphasize outreach to groups like yours, so your coming is particularly appreciated.
14:04:56 <dka_> ACTION: Yehuda to send a note to the web audio working group with some architectural suggestions.
14:04:56 <trackbot> Created ACTION-811 - Send a note to the web audio working group with some architectural suggestions. [on Yehuda Katz - due 2013-06-06].
14:04:57 <noah> OT: This is actually very helpful to me in jogging me to think more carefully about how these decisions came to be made. I think this one was made quite quickly.
14:06:51 <noah> WE ARE ON BREAK FOR BIRTHDAY CAKE
14:43:17 <dka_> dka_ has joined #tagmem
14:46:08 <noah> topic: System Applications
14:47:11 <marcosc> https://github.com/sysapps/
14:47:35 <marcosc> WG link: http://www.w3.org/2012/sysapps/
14:49:56 <noah> DKA: We'll check whether Mounir Lamouri can join us for this session. He is co-chair of the sys apps working group.
14:50:23 <noah> MC: What's good for the TAG here?
14:50:45 <noah> DKA: Maybe from an API design perspective. Also where the group sits, updates on controversies, etc.
14:51:39 <noah> MC: http://www.w3.org/2012/sysapps/#roadmap has lists of deliverables. Manifests were transferred to Web Apps on 21 May 2013
14:52:19 <noah> MC: App URI stuff is in the same space as the old Widget URI stuff
14:52:45 <noah> MC: Scheduler allows apps to be descheduled and wake up. (Scribe thinks others are self-explanatory)
14:53:13 <noah> HT: How would I know whether some new API I wanted to build to into Sysapps vs Web Apps
14:53:46 <noah> MC: These tend to be very privacy and security sensitivity. These will likely not be exposed directly to user code (scribe hopes he got that right?)
14:54:09 <noah> MC: Admittedly a bit odd for someone building the Web platform
14:55:00 <noah> DKA: Your wording seems problematic. Even saying they're not in the "browser context" can be picked apart. I don't think these are not "exposed to ..."
14:55:08 <noah> NM: Well, to which code are they exposed?
14:55:19 <noah> Several: typically, to certified apps.
14:56:17 <noah> ML: In Firefox, different ones of these are exposed at different levels. Also, these need not only be implemented in browser-like containers, at least for now.
14:57:41 <noah> MC: Dan asked, how are we doing API design. Rule of thumb has been: take existing APIs from Firefox OS, Tizen, etc. Those formed a starting point. We refine to make sure they are idiomatic Javascript apis. We send them to public-script-coord, which hits combination of Web apps and script communtities. Great feedback is being received, and we try to fix things.
14:58:02 <noah> MC: For example we've taken a quick check on use of futures, and we're prototyping at the same time.
14:59:36 <noah> MC: Process is very open, doing all work on Git Hub
15:03:40 <noah> DKA: Maybe we should review some particular features. E.g. there's confusion about Web Sockets vs. Raw sockets
15:04:43 <noah> MC: Web Sockets checks all sorts of headers to enforce security. Raw sockets are just that. You can do, e.g. an IMap connection.
15:05:01 <noah> ML: Some range of ports is available to packaged apps.
15:05:23 <noah> MC: Not sure that's in the spec yet. Not much is yet explained about security details.
15:06:47 <noah> ML: Sometimes issue discussions happen on Git Hub and aren't visible enough to the wider community that follows the e-mail list.
15:07:26 <noah> MC: Similar issues may come up if the TAG moves toward Git Hub
15:08:31 <noah> YK: Some advice: when people collaborate, some people want feedback, but that doesn't work as well as collaboration.
15:09:11 <annevk> (261 subscribers)
15:10:55 <noah> NM: Some concern about whether this will work for TAG members who depend on email
15:11:59 <noah> AR: You can rig Git Hub to send emails
15:13:14 <slightlyoff> noah: to clarify, I was saying that GH sends mail to participants in threads, and that users can subscribe to repositories
15:14:14 <noah> NM: That's great. I'm just encouraging you to think about the very broad community of readers of www-tag who depend on that list to give them a broad, long term alert on a broad range of things that the TAG is involved with. I'm suggesting that you make sure they can find and get involve in the discussions that are of concern to them.
15:14:46 <noah> AVK: I thought this session would be more on...I thought this was more going to be on packaged apps.
15:14:59 <noah> Several: we have a later agenda item for that.
15:15:04 <noah> AVK: Oh, OK. Either way.
15:15:55 <noah> DKA: If you want to have the assumption that you want to build the dialer using the Web...
15:16:04 <noah> YK: Don't call that the Web
15:16:27 <noah> DKA: Well, that raises the important question  of what the Web is.
15:16:41 <noah> YK: Not happy if that means only discussing downloadable packaged apps.
15:17:10 <noah> AR: I'm happy with how things are going.
15:17:37 <noah> DKA: The Firefox OS and Tizen communities are collaborating. Do we know about Chrome OS.
15:17:45 <noah> ML: They're saying maybe someday
15:18:00 <noah> YK: Well, they're doing their own chrome.* APIs.
15:18:07 <noah> AR: I'm not sympathetic
15:18:22 <noah> ML: I think it's not so bad. It's at least a useful experiment.
15:19:37 <noah> YK: There's a general API review question, but a repeating concern is access to only one device/sensor/etc. at a time.
15:19:53 <noah> MC: I've been working with Rick Waldron on that
15:21:04 <noah> DKA: Move on to packaging? We have 3 topics which are: 1) the device APIs 2) packaging a Web application e.g. in zip file (YK jumps in to object to use of term "Web" in this context) and 3) security
15:21:36 <noah> topic: Packaged Apps
15:21:55 <noah> ML: In Firefox OS we have hosted apps which have only hosted apps, which have almost no priviledge...
15:22:11 <noah> DKA: Is there a difference between that and something I visit on the Web?
15:23:30 <noah> ML: Well, it has an application manifest, launch path, icons, and metadata. Other than that, it's just a Web page. It's installed and has just a little more privilege for just a few things. E.g. can change screen orientation or go full page, because we assume an app you explicitly install you trust to do that.
15:23:59 <noah> AVK: Also, gets it's own cache context
15:25:27 <annevk> following a link will launch the browser app (long term plan)
15:25:39 <noah> NM: Has download for more than the page itself?
15:25:49 <noah> MC: Uses the regular appcache
15:26:23 <noah> MC: ..shows examole... with, for example, "appcache_path": "/cache.manifest"
15:26:37 <noah> The manifest appears to be JSON
15:27:28 <noah> NM and AR: Do you get FWD/BACK
15:27:44 <noah> YK: Not in the usual sense, but you can use the history APIs
15:28:09 <noah> ML: All the things like cookies, cache, etc. are in isolated contexts from other apps
15:28:38 <noah> AR: If I've previously browsed to facebook.com and authorized, then go to the downloaded app, do my authorizations carry over?
15:28:45 <noah> ML: No
15:28:54 <noah> MC: Can be problematic
15:29:19 <timbl> q+
15:29:32 <noah> s/MC: Can be problematic/DKA: could be problematic for o-auth/
15:30:06 <noah> MC: The CSP defaults are not changed, but you can narrow them.
15:30:32 <noah> TBL: OK, so these are untrusted. Let's say I want to write a browser, or an app that can integrate my linkedin and Facebook data. Are you providing for that?
15:30:49 <noah> MC: Yes, in the same way as Web today. Relying on CORS and RESTful APIs on the server.
15:30:58 <dka_> dka_ has joined #tagmem
15:31:02 <noah> TBL: So, I can give it raw socket app?
15:31:07 <noah> NM: That's not this class of app.
15:31:24 <noah> TBL: Is it in the install sequence?
15:32:31 <noah> ML: Right now, it's going through a marketplace that will vet your application before distribute it. They are given app: URIs, which means local to your system.
15:32:54 <noah> TBL: You could do things with signed manifests, though people gave up on that. Anyway, so you have to go through the marketplace.
15:33:19 <noah> TBL: Are there multiple marketplaces?
15:33:24 <noah> ML: No.
15:33:33 <noah> NM: I think that's a Firefox OS answer, not an API answer, right?
15:34:17 <noah> DKA: This is where I wanted to go, I.e. to discuss packaging and URIs. Not sure it's broken, but want to discuss. We keep asking about packaged apps, whether such apps are part of the Web, and how use of URIs might improve the story.
15:34:23 <noah> TBL: Interesting, but not where I was going.
15:35:01 <noah> TBL: The reason people push back on DRM is that it breaks your ability to program your own computer. Cory Doctorow doesn't want to steal movies, he's worried about loss of ability to program his own computer. This raises similar questions.
15:35:23 <noah> TBL: Can I rebuild iTunes. Now I have to go through SteveJobs/Firefox-central to be allowed to do it?
15:36:26 <noah> ML: There are alternatives. That's one of the reasons we (Mozilla) pushed for the non-Samsung API to allow multiple marketplaces, active at the same time.
15:36:38 <noah> ML: We do want to make sure only trusted apps are trusted.
15:37:08 <noah> TBL: It's logical that I might want to trust not only Firefox-signed apps, but also if I work for Merrill-Lynch, apps signed by them. I might also want multiple review.
15:37:35 <noah> ML: So, we currently trust only our own.
15:37:55 <noah> TBL: Saying you can do it by hacking it isn't satisfying for non-hackers
15:38:13 <noah> TBL: I want to set up my family with more than one marketplace. I think they're all trustworthy.
15:38:43 <noah> YK: I think Mozilla's view is they want to have this control over security issues.
15:39:03 <noah> ML: More subtle than that. We need a good security story around some APIs, so we restrict them to packaged apps.
15:39:40 <noah> TBL: That's my issue. I'm not asking why can't I have a Web app in my store.
15:39:52 <noah> YK: I think the goal is that control fo
15:40:15 <noah> TBL: There are two reasons Mozilla want control 1) take over the world and spy everyone and 2) operating on your behalf to help you avoid installing bad code.
15:40:58 <noah> AR: This is the same question as cert authorities. People have distributed across their systems (artifacts supporting) contracts we've agreed on.
15:42:28 <noah> NM: I think Tim wants to register.
15:43:01 <noah> AR: You misunderstood my analogy to certs. You're sort of packaging the trust abstraction (scribe invented those words to approximate AR's thoughts...not sure he got it right)
15:43:16 <noah> ML: What you've just described I would like to see. Our time is limited.
15:44:07 <noah> ML: I'm trying to get people at Mozilla to "force trust as package". We might want to trust Google not to do evil things.
15:45:21 <noah> DKA: It seems to me there are two separate issues here. 1) is it reasonable that packaged apps that are installed should explicitly have more permissions...whether or not there's a chain of trust to the store...is there a real difference if I explicilty install a malicious app vs. just doing it from the Web.
15:45:43 <noah> TBL: I agree. Whether it happens to be zipped or manifested should be orthogonal to the trust issue.
15:45:57 <noah> YK: I heard yesterday it has to be packaged.
15:46:33 <noah> ML: The reasons both Mozilla and Google are doing this include that offline storage is a mess at the moment.
15:46:42 <noah> TBL: That's temporary.
15:46:59 <noah> ML: Also, some developers like the ease of zipping up.
15:47:09 <noah> TBL: I want to go back to the trust issue.
15:47:32 <noah> YK: I've heard repeatedly that we need a packaged app so there's something review. So we need a chain of trust to establish who gets to review.
15:47:41 <noah> [scribe missed something]
15:48:33 <annevk> but but but I don't want stores
15:48:40 <noah> :-)
15:49:33 <noah> NM: But why can't the user be at the head of the chain of trust. So I authorize a store owned by W3C or EFF to source trusted apps to my phone.
15:50:11 <annevk> the whole store model is so much copied from Apple and very much anti-web
15:50:19 <annevk> I don't understand why it's taken as given
15:50:49 <noah> TBL: Well, good goal, but there are problems with people getting false rumors about what to trust. You can imagine both union and intersection stores. Union: I accept apps from Firefox or Netflix or W3C. Also intersection stores: I want it to be trusted by both Firefox and Bank of America (for limited use...not Cory Doctorow's)
15:51:00 <noah> TBL: I want to be able to set these ups.
15:51:03 <noah> s/ups/up/
15:52:50 <noah> AR: There's a core question of ownership that's deep. It relates to the implementation details. To get a secure boot, you need to put a cert in the code that's checked by the hardware. We have devices doing this. A lot of phones will trend this way, because nobody likes their phones owned. There will be a root of trust be swappable.
15:53:06 <noah> AR: Ultimately you need to swap the root of trust.
15:55:39 <noah> NM: Yes, you ultimately need control over which root certs are trusted if you want to boot your OS. That's important. But it's also useful if a widely used system like Firefox OS take the trouble to let me trust stores that I want to trust without throwing out all of Firefox OS.
15:56:06 <noah> YK: The question is, do we want to find a way to let Web apps have these permissions.
15:56:26 <noah> TBL: I know you want that, but I want just now to discuss supporting multiple app stores.
15:56:36 <noah> AVK: But that's just copying Apple's model
15:57:27 <noah> AR: It's easy to join in your mind the notion that to check these permissions you need the central coordination. I'm not sure that's essential.
15:57:59 <noah> AR: I think instead of supplanting the root of trust, which is hard. To get to a world where people don't believe the Web owns them.
15:58:08 <noah> TBL: It's not hard, it's dangerous.
15:58:27 <noah> YK: Either you download or you write all the apps yourself.
15:58:56 <noah> TBL: No. I use stores because I talk to people about which ones are good. I want to listen to music and see down the left iTunes, Google Play, etc.
15:59:07 <noah> TBL: It need not be dominated by one.
15:59:10 <dka_> q?
15:59:10 <wycats_> q+
15:59:25 <noah> YL: The app store is giving you an annotation that says the code is safe.
16:00:36 <noah> YL: If you replace that by a company on their own Web site, you have the same thing more distributed.
16:01:11 <noah> TBL: I don't care if you call it a store. Let's say GitHub puts up an install this app button. If people live dangerously, let them.
16:01:37 <dka_> ack wycats
16:01:49 <dka_> ack timbl
16:02:17 <noah> YK: I think continually looking at the App Store model isn't useful.
16:02:31 <noah> DKA: Are app stores and central authorities really the same?
16:04:10 <Yves> App Stores are just an implementation artefact
16:05:57 <noah> DKA: I have an app that uses a dialer of my own, that's better than the default, and I'd like every app to use mine. It's effectively a hosted app. ...is that the Web
16:06:22 <noah> YK: Does it have network permissions?
16:06:33 <noah> DKA: Let's assume that it does.
16:07:40 <noah> AR: Consider Firefox OS. A huge portion of the Web security model winds up creating permissions that some othre tab can abuse. Things be hosted in iframes, against my will.
16:08:18 <noah> AR: You said what I hoped. It changes this dynamic. It still has URI, still has state, I could download and cache anything, but the risk of leakage is much lower.
16:08:56 <noah> AR: There's a question about interaction of domains that's the core of the security question, and that we can tease apart.
16:09:31 <noah> YK: My thinking is that packaged apps are a quick approach to getting them into the platform.
16:16:53 <noah> NM: I think a very important characteristic of Web content and applications is the core of the Web: you link from one thing to another. Gmail feels like a Web app. I get there by following a link and I can link out of it. Why is it a mistake to install a packged gmail so that all the same things work offline.
16:17:29 <noah> YK: Playing those tricks it's difficult to get the edge caess.
16:18:26 <noah> ML: Android and Firefox OS both pattern match on URIs and will open certain prefixes in installed apps.
16:19:31 <noah> NM: What he's saying is that historically, the mediation between apps is in the os.
16:19:46 <noah> AVK: My vision is a URI bar everywhere.
16:20:20 <noah> TBL: What ft.co wants to do is they want to download the paper for today. They want to be able to intercept.
16:21:27 <noah> NM: Anne, that's an appealing vision, but not for everywhere. On systems like Android, the list of URI prefixes and associated apps is owned by the OS, not the browser.
16:21:48 <noah> YK: I think Anne says there's a gap between packged and apps and URIs
16:21:58 <noah> ML: Please stop talking about packaged apps.
16:22:11 <noah> YK: We do you need a Web activity for a hosted app
16:22:19 <noah> ML: You need to know whether to open the browser.
16:22:31 <noah> AR: App wants to say: please route bits of this URI space to me.
16:22:54 <noah> Noah likes AR's view of ths.
16:22:59 <noah> s/ths/this/
16:24:14 <noah> AR: Imagine I have a bit of URI space that I have previously installed as an application on my homes screen. It launches with no chrome and has local state. I click a link that someone sent me, and I want to be able to say does the app open in the tab, does it get a new context, etc.
16:24:24 <noah> AVK: Your model is of a typical os with apps etc.
16:24:38 <noah> AR: I'm not saying that.
16:24:48 <noah> AVK: You are phrasing it as an app.
16:25:17 <noah> TBL: I go to a set of Web pages, all linked, with a set of pages with arithmetic tests for children, e.g. 2*3, 2*4, and indeed potentially unbounded.
16:25:30 <noah> TBL: A completely virtual space generated by Javascript.
16:26:13 <noah> TBL: What I want is if someone sends me a link to 12*13 I want it to know all my local state, because >I< have shown myself good at math. I want it to look like Web, links from page to page.
16:26:49 <noah> TBL: Yehuda, that's what I want.
16:27:03 <JeniT> annevk: "you don't need an app for that"
16:27:11 <noah> AVK: We should have that in a year, but without an app.
16:27:37 <noah> Your scribe is going to run out of gas soon :-(
16:28:18 <noah> YK: My concern is that there are fiddly details that may make this hard in practice
16:29:05 <noah> TBL: We've agreed there's a need to distinguish pages to which you've given trust, and those you haven't
16:29:20 <noah> ML: Right, but in other respects, a hosted app and a Web page are the same thing
16:29:54 <noah> AVK: Facebook.com will be different from the hosted app
16:30:05 <noah> YK: The problem is if most people feel they have to implement everything twice
16:30:27 <noah> TBL: I think there's a fear you're trying to get at, but you haven't expressed it well
16:31:23 <noah> DKA: are we at point of diminishing returns? There's been good insight, but not clear output.
16:31:40 <noah> TBL: On board are five things to keep separate.
16:32:01 <JeniT> scribing timbl's notes from the board
16:32:17 <JeniT> * multiple stores/keys vs single
16:32:32 <JeniT> * ultimate control user | mozilla/chrome/apple/sony | vodaphone/orange
16:32:38 <JeniT> * packaged apps vs web apps
16:32:54 <JeniT> * prohibited vs cordoned-off vs allowed
16:33:03 <JeniT> * issue of linking to stuff in app: space vs http:
16:34:06 <noah> topic: F2F
16:34:45 <noah> DKA: We had agreed 13-15 October. Now we find that Tim as well as Yehuda can't make it
16:38:22 <noah> TBL: How about 1-3 October?
16:38:30 <noah> General agreement.
16:38:55 <noah> TC 39 is Sept 24-26
16:39:02 <noah> in Boston
16:39:31 <noah> YK: Even a day earlier Mon-Wed is better
16:41:04 <noah> TBL: I can definitely do 1-3 Oct, and probably could do 30 Sept through 2 Oct.
16:41:28 <noah> AR: 30% chance I can't make it, won't know for a month
16:41:32 <noah> DKA: need to check with Henry
16:42:08 <noah> Marcos, Yves, Dan, Anne, Peter, Yehuda and Noah (if needed) are all OK
16:42:11 <darobin> darobin has joined #tagmem
16:43:26 <noah> ADJOURNED
17:07:15 <darobin> darobin has joined #tagmem
17:59:33 <ht> ht has joined #tagmem
18:11:30 <annevk> annevk has joined #tagmem
18:27:04 <Zakim> Zakim has left #tagmem