W3C

- DRAFT -

Technical Architecture Group Teleconference

30 May 2013

Agenda

See also: IRC log

Attendees

Present
Tim Berners-Lee, Yehuda Katz, Peter Linss, Anne van Kesteren, Alex Russell, Dan Appelquist, Yves Lafon, Henry Thompson, Noah, Mendelsohn, Marcos, Caceres
Regrets
Chair
Peter Linss, Dan Appelquist
Scribe
Jeni Tennison

Contents


<trackbot> Date: 30 May 2013

<JeniT> Scribe: Jeni Tennison

<JeniT> ScribeNick: JeniT

Noah's thoughts as outgoing chair

noah: I hope to keep this short
... I've been on the TAG for 9 years
... chair for 4 years
... the role of the chair is to help the group think about what success is, and to help them deliver
... there are lots of new people in the group, and it's reinventing itself, and that's great
... none of this should be seen as an intention to stop you doing the things you're doing
... these are reflections for longer term
... this is an unusual group
... other groups have clear deliverables, and customers waiting for your work, who want to build on it
... there's a route for feedback in working groups
... we don't have that in the TAG
... one failure mode is thrashing on stuff that isn't focused
... worth reflecting on what the scope of the TAG is, and having 70-80% of the work fitting within that scope
... you are the senior technical steering committee for the web
... the only other steering committee does finances and stuff
... and the web is a really critical part of the world's infrastructure
... evolving much faster than the phone system etc
... you have responsibility for a system that's really important and touches a lot of things
... from time to time think about it that way
... stretch out beyond your comfort zone sometimes
... you all have expertise in lots of important stuff, but
... you may find that what's really important next year requires
... you to come up to speed in new areas.
... For example, when Henry brought up the use case of librarians
... and whether they could use URIs given the persistence they need
... from time to time ask where the opportunities are
... you have to ask what makes the web different and valuable
... my answer comes back to Metcalf's Law, or network effects
... a virtuous positive feedback cycle where adding things to the network adds value to the whole web
... that gives you an imperative to think about things like how international the web is
... there was a time when putting a web server in a printer would have seemed weird
... now we take it for granted
... the TAG needs to think like that, but with some guiding principles
... ask yourself about whether it's worth being able to link data into the rest of the web
... you can get very busy working on stuff that you know is important
... Web app developers are not a reliable proxy for everyone you have to worry about
... they're not a proxy for librarians for example
... This is a plea to think about the potential and the risks for the web.
... This forces you to go outside your comfort zone.
... Don't just keep in touch with the communities that you know about.
... The other thing I'd say is that we're the architectural group, and it's not entirely clear what that means
... this group should make sure the web works in 30/50/100 years
... phone numbers were built to scale, they scale to mobile
... think about building to scale
... for example, I think the surface area should be kept small
... you can decide what matters, I'd encourage you to think about it, to try
... It's easy to make decisions in an agile way when you have contact with your users, in an agile way,
... but it's an art to make design decisions without that, as Tim did.
... I'd encourage you to look at Tim's design notes
... a lot of what's in WebArch is a clarification and cleanup of those thoughts
... that doesn't make them all right
... but if you're on the TAG, I'd encourage you to look at the decisions that Tim made
... sometimes you should stand up to people, making longer term decisions
... when you do these things you can be wrong
... for example, we could see long term benefits with XHTML, and eventually the community came back and said it was wrong
... the three pillars of web architecture are URIs, HTTP and HTML
... Tim has said in order of importance they are URIs, HTTP and then content stuff (HTML, CSS, JS)
... a lot of stuff we're looking at at the moment is in the third category
... you should look for things in the first two categories
... in particular linking
... because that's what makes the network
... the reason people don't stay in iPhone Apps is because they want to visit other things on the network
... that's why it's important to think about unique names
... for example, what about internationalised names?
... one last thing
... it took me a while to realise how many ways Tim's presence adds to the group
... Tim works on a much broader range of this stuff than most of us do
... I'd encourage you to find ways to take advantage of not only his smarts and expertise, but also the scope of his contacts and his
... involvement in a broad range of initiatives.
... Finally
... because there's no one asking the TAG for specific deliverables,
... you have to be very motivated.
... There's a huge amount of stuff to go out and proactively get into:
... work hard, make it easy for your chairs!
... and thank you
... thank you for Tim for making me part of this

timbl: thank you for chairing for such a long time, and for your contributions

ht: I'd like to follow up on one thing that noah said
... W3C has not done as well as we wish we had at having user representatives highly visible
... there are a handful of people who are clients
... users are underrepresented in the W3C
... they're a constituency that the TAG needs to keep in view, because no one else is going to do that
... that's a corollary of noah's point that the dev community are not the only customers
... not the only people we're responsible to
... trying to balance the requirements of different classes of user agents and different types of users are really important

dka : the point about linking is really important, one of the things I want to bring up in the packaging discussion
... how do we have a packaged app and still use linking
... if it's possible, should we be influencing the work in that way

Futures / Promises

slightlyoff: we often create APIs which take the form dothing(opt1, ..., callback)
... where callback is a function that takes a single value

timbl: where the value passed in is the context

noah: you get context from the closure

slightlyoff: the simple synchronous version is contents = read(opt1, ...)
... in the synchronous version you'd wrap it in a try/catch
... that doesn't work in an async version
... so you end up another parameter for the error, or you have a separate error handler callback
... this shows up in a lot of APIs
... often when you're doing IO

timbl: the contract is that you'll get only the main callback or the error callback called?

slightlyoff: it happens on a WG by WG and API by API basis
... there are all kinds of patterns
... you might get an operation handle back
... op = read(...);
... op.onsuccess(...).ondone(...).onreadystatechange(...).onprogress(...)
... there are many different names for success
... they all reify down to a single event handler
... function(evt) { var controls = evt.value, evt.contents etc }
... there's a temporal dead zone between reading and binding event handlers

marcosc: this is freaking awful

slightlyoff: what people end up with is that they do the callbacks at some time in the future
... this can be linked into the HTML event loop
... some APIs define this well, some don't
... it's weird, it's verbose, there's inconsistencies
... it makes it hard for developers to work with

noah: almost every OS eventually gets an eventing system

slightlyoff: we should be driving towards a standard way of doing this
... this shouldn't be hard

timbl: what you're trying to do is express something in a synchronous kind of way in a asynchronous world

slightlyoff: promise = read(...);

noah: there's a type that is returned by read() which is consistent across APIs

slightlyoff: that's right, you can have p.then(func(v) {}, func(e) {}).then(...)
... then is called immediately but the functions aren't

noah: the read() delivers the value to the promise, the promise delivers the values to the functions

slightlyoff: you can call then multiple times

timbl: the thens occur in any order?

slightlyoff: they're dispatched in the order they're registered

ht: how does f2 know the name of the promise?
... how does it chain?

slightlyoff: the then() creates a new future
... so you can chain another then() on that future
... this is an important standard way of doing this historically
... many languages have this, for example Python has futures
... Javascript has no syntactic support for it, so it's just through these functional contracts
... C++ has Futures for example
... JS has gotten by with libraries that are similar to this
... they're really common, and people are using this pattern at scale
... so we want to get our house in order from the DOM perspective

ht: if there's no language-level support for this, how do the libraries which implement these solve the race condition problem?
... if they have to just work with callbacks

slightlyoff: in the web platform we have several APIs that give us the ability to delay work for the next turn
... they give you the ability to run code soon but not synchronously

timbl: timeout(0) for example

slightlyoff: JS and the DOM get along but don't have a contract
... JS has no idea of an event loop
... we're hoping to add something in ES7
... the DOM has been responsible for everything to do with time, except getting the time from the system clock
... the libraries use a call-me-back-soon hook

[discussion of GC]

noah: for medium/high performance this'll give you what you need

slightlyoff: this gives you standard ways for error handling too

timbl: I've found things get lost currently, do we get a guarantee that one of these things get called?

slightlyoff: I will talk about that later
... there are lots of libraries, want to make them compatible, have made Promises A+
... a proto-standard scrum, to standardise just the essential pieces of this contract
... eg number of arguments, the timing
... not the rest of the API design
... DOM needs this badly
... JS needs it too

timbl: which bits?

slightlyoff: generators and iterators which are nearly pythonic in their style
... and which aren't explained, they're just syntax
... it would be nice if we could describe them as promises
... in most cases we're on the UI thread

wycats_: we need them for modules

slightlyoff: it helps us reason about IO
... it would be good if both DOM and JS had a standard contract for their users
... since January we've been working with the Promises A+ community and the library authors

wycats_: all the pure JS libraries have coalesced around this

slightlyoff: annevk's draft locks down the ambiguities
... this is good for DOM
... we can make backwards-compatible fixes to existing APIs by returning a promise rather than void
... we want to make sure that APIs standardise around this same pattern

timbl: so this has consensus?

slightlyoff: there's no active hostility

annevk: there's some debate about specifics

slightlyoff: this was a hot topic at TC39 last week
... the big change is that we've renamed 'Future' to 'Promise'

timbl: was there any change to semantics?

slightlyoff: no
... there are two camps about how to use these things in the wild
... generally coming from perspectives of producer vs consumer
... the Promise can be thought of as the value
... or you can think of the value being received at another time

wycats_: abashed monadic promises

slightlyoff: we've won this battle in TC39 and DOM

annevk: you should say 'platform APIs' rather than DOM

slightlyoff: yes, we have agreement to use the same design, and to coordinate
... and it will eventually end up in the language

<wycats_> you should consider this TAG work

dka_: what can we as the TAG do, what's the output of our work on this?
... and what external bodies should the TAG be influencing to get consensus & buy-in?

marcosc: from a WG perspective, where we've been trying to use these things is guidance on how to hook into the spec
... like examples

annevk: the spec doesn't have hooks yet

marcosc: if the TAG made a document that gave examples for spec authors
... to make sure we're using the right language

wycats_: an explainer

timbl: is there JS for implementing it?

slightlyoff: yes, I've written one for example

wycats_: (to DKA) you should consider this TAG work

dka_: making that assumption, what is the output of the TAG?

annevk: note on promises

wycats_: a 'how to make APIs' guide that fast-tracks Futures

dka_: it's useful to be able to point to a document in TAG space that has the links to the relevant work

marcosc: and bug annevk to make sure we can hook into the spec

slightlyoff: we're not finished on the spec
... we've been successful at preventing design needs from leaking into the superclass
... eg notification of progress
... you need a subclass of a promise to give that
... need to get agreement on common subclasses
... the TAG could help spec authors understand how useful it is to have a common contract
... we've backdoored this because libraries have agreed, just have to standardise it
... the TAG should weigh in to say it's a good thing to do

timbl: have every jQuery implementation have a complete Promise API?

wycats_: it's an evolving story

slightlyoff: there are many opportunities here
... if we have a standard platform Promise type it's possible to add tools
... eg to show a list of outstanding promises that haven't been resolved
... if we can't standardise on a type we can't do that

wycats_: all existing libraries can wrap jQuery promises to create ones that meet their APIs

timbl: what's nice about try/catch is you can wrap it around a whole bunch of stuff

annevk: you can combine promises into a new promise

wycats_: the design is to make it easy to express things as if they were synchronous
... xhr.then(success).then(success2).then(null, err)
... and that desugars into try { xhr(); success(); success2(); } catch (e) { err() }

<annevk> Yves, ETA is a week or two, not sure if you asked that

<annevk> Yves, ETA for renaming that is and fixing a few things

<Yves> yeah, I was asking for ETA on the new version of the spec

timbl: what you want to do is write an asynchronous case in as concise a way as sync ways

slightlyoff: we can't get there without this

wycats_: in unix you have file descriptors for example
... but you need the abstraction first, something that represents the eventual thing from IO
... you need the primitive first

slightlyoff: this is the primitive
... and this is why I think the TAG needs to help drive this through the platform as quickly as possible
... it would be best if all the platform APIs use this pattern
... in the same way as we're relatively uniform over events
... there will be a similar issue over Streams
... there's no core idea of Streams
... then ES7 will probably bite off language-native events
... and it would be good to make sure that was unified with DOM events
... from an architectural perspective

timbl: using a promise has an overhead but is the idea that in the future will the language optimise it?

slightlyoff: anything that's common enough will get optimised
... especially if it's targeted by benchmarks
... having it standard opens up possibilities for optimisation
... it's never going to be actually free

wycats_: V8 happily optimises DOM constructs

slightlyoff: the more that V8 knows about the internal representation, the more it can do

plinss: what are the concrete next steps for the TAG?

slightlyoff: I need help convincing spec authors that this is a good thing to do

timbl: write what you think and we call it a Finding
... then you get a TPAC slot to point people at it

dka_: I think that fits nicely in how we described our work
... we have Note on Promises on the list
... this gets into the question of how we operate
... I'd like to see placeholder document for that before the end of the meeting
... which we use as a reference point
... if you have a commitment to write the content of the document, we can start shopping it around
... we can use it as a basis for the group engagement that we talked about yesterday
... even starting with discussion on web audio

plinss: we have to get consensus on whether this is something the TAG wants to throw its weight behind
... TAG Finding + TPAC slot might be appropriate, but do we need something quicker than that?

marcosc: it's hard to move people off the events model, so it needs to be clear how and when to do that

wycats_: the explainer needs to go into benefits and limitations

timbl: common open source code too?

marcosc: Alex has done some work on IndexedDB & LocalStorage for example, refactored

timbl: is it horribly cumbersome to do that?

marcosc: it's nice. The XHR example is very easy to understand
... integrating with events too

timbl: you mean the developer is using events as well?

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
... showing that is 20 lines of code and very useful

ht: that's a very high leverage way of engaging the web community

plinss: do we have consensus?

[yeses]

JeniT: what are the arguments against?

wycats_: one argument is the monadic promises thing
... which I think we can leave TC39 to argue
... the argument that is more relevant is from Node.js
... they coordinated around error-first callbacks
... where errors are called as the first parameter

slightlyoff: those are nicer in some ways
... by presenting the error as the first argument, the fact there might be an error is emphasised

timbl: I standardised on that because I was losing too many errors

wycats_: if you choose to use that pattern, you'll handle the error

slightlyoff: we can evolve Promises to do error-first callback

wycats_: error-first callbacks don't separate the call from the eventual value
... so it's hard to build abstractions around it
... you have to use all() around a bunch of functions
... it's hard to do combinations

annevk: the concern I've heard the most is completely different, that they're not stable yet

<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

slightlyoff: yes, there's disbelief and unfamiliarity

wycats_: many people using Node.js use libraries that use Promises

timbl: the TAG can show the adoption path
... to show that new libraries can support old code
... demonstrate there's only benefit in supporting promises
... push it to libraries, then to developers

noah: are they actively pushing back?

wycats_: they can't avoid adopting, because they use V8

annevk: there are two conversations, one around the platform APIs and one around error-first callback

<wycats_> https://npmjs.org/package/q

<wycats_> 322 dependents

noah: we have to coordinate across W3C and others
... Node.js has expertise in dealing with async stuff, and they're objecting
... are they worried about object creation overhead?

wycats_: I haven't heard them bringing up performance

slightlyoff: you're already creating objects, in either model
... the Node.js community doesn't have the same latency issue as a game developer

<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...

noah: if the TAG is coming close to making a resolution, we should reach out to that community

wycats_: even if it doesn't solve Node.js's problems, it solves platform API's problems

slightlyoff: the Node.js community isn't our community
... it's divorced itself from standard web APIs in several cases
... for example inventing a module system diverting from ES6

timbl: can I propose we wrap-up Futures/Promises, and queue as an agenda item the relationship between Node.js and the platform

dka_: I suggested a clarification to the resolution wording

<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

<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

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

Yves: is it too early to write a document?

wycats_: no

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

ht: I wonder if we should try for a W3C workshop on this

[BREAK for 20 mins]

<Zakim> ht, you wanted to suggest a workshop

ht: we should have a workshop on the larger topic of platform API stakeholder consistency

marcosc: primitives

Yves: something at TPAC?

ht: possibly
... W3C workshops are another tool that we could employ

wycats_: the process of workshops aren't familiar or helpful for web developers
... particularly requiring position papers

ht: it's possible to have workshops without requiring position papers

noah: was the meeting a waste of time?

wycats_: it ended up meaning the workshop didn't contain developers, which made it less useful

slightlyoff: there were meetings last year that I participated in
... an invited group of people
... that and W3C workshop have similarities and impact
... the difference in style gives different outcomes

wycats_: you're too charitable
... at the workshop and developers at the Offline workshop
... the developers & annevk & darobin removed ourselves from the workshop
... the predefined structure of the workshop didn't work

dka_: in defence of workshops
... I understand the issues, but part of the point is to try to be an open forum
... what Alex described is a bunch of people who know each other
... the whole idea of the W3C workshop process is to announce publicly that it's going to happen
... to try to get people in the room who aren't talking to each other already
... and the point of the position papers is to eliminate kooks
... you have to have something coherent to say

wycats_: the people who wrote position papers were kooks

timbl: philosophically, if you want to get people together you have to find a way of doing it
... we found too many people coming to workshops
... we found that asking for a small paragraph in email as a position paper set a bar
... later as things got bigger we found that we needed a programme committee
... workshops shouldn't turn into conferences
... think of a way of getting the right people in the room

wycats_: I was invited but I wasn't able to speak

marcosc: it was an unconference!

wycats_: most of the people there weren't familiar with the actual problem

dka_: let's discuss this over lunch

wycats_: we have to discuss this before I'm happy with a workshop

Yves: this is why I suggested TPAC because you can present to a larger amount of people

<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]

<Yves> and more generally WG that would need to hear about such topic

noah: you're over thinking this
... if a workshop is potentially promising, make it someone's responsibility to organise it
... asking people to write stuff in advance is a good thing because it helps people think about what they want to say
... put it together in an appropriate way for getting the people you want in the room

<annevk> Basically, we should have a barcamp around the web platform. Workshops / conferences are a pain.

dka_: I was one of the chairs of the Offline workshop, so I want to know about what was wrong about it
... for this topic, we can move on

Streams

annevk: we don't know enough about this to talk now

TAG operations

dka_: we've talked about enough content to be able to ground this discussion about how we operate

plinss: the one thing on Promises to tidy up is a next action

dka_: marcosc, you gave a briefing to the SysApps WG about how to operate, I was wondering how much of that we could adopt

marcosc: there's what I did with SysApps, and what slightlyoff, wycats_ & annevk have done with private repos that they've then opened up
... we have a github organisation & repo that JeniT's already used for her slides
... it's easier in some respects than CVS
... on the other hand there's lots of infrastructure currently in place for the TAG
... like generating minutes etc it's super useful

<annevk> https://github.com/w3ctag/ exists

dka_: how we use github and moving things over to github is one key topic

annevk: we have a github organisation already

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
... sometimes that's useful to get coverage with IP rules
... I've been told that some WGs have cloned repos into W3C space, but I don't know about the control over URIs

<annevk> Btw, if people can give me their usernames I will add them

<annevk> Yves, plinss, dka_, ht, timbl?

timbl: github does not naturally allow you to host a website, it doesn't give you control over mime types

wycats_: you can manage those within github

ht: what's wrong with CVS? it's not broken

wycats_: other people who don't have CVS access can't collaborate with you

ht: if we have projects that need collaboration, fine, but we don't always need collaboration
... can't we use CVS for most of our work, and use github when we want to collaborate

timbl: Henry's concerned about public write access

wycats_: github doesn't give public write access

dka_: this is why I asked marcosc to introduce the topic from the perspective of other WGs
... then we can talk about how we mix this approach with the existing W3C approach to get the best of both worlds
... this isn't an either/or

noah: my question was about what control you get over URIs

marcosc: currently, W3C has a htaccess file that redirects from W3C space to github space

noah: is it easy to make multiple URIs and include dates in URIs?

marcosc: yes

wycats_: there's a huge gap in understanding about how github works here

dka_: noah, you're conflating how we are doing it and how we should do it

noah: we've needed dated versions so that we can discuss drafts in meetings and having a dated version referenced from the minutes

marcosc: when you check something in, you can see diffs for changes

wycats_: you can do everything you want to do with tooling on top of gh-pages

noah: when the URIs are mirrored from W3C space, do you get stability?
... what happens if/when github blows up?

wycats_: we can move the network storage and get the URI persistence

timbl: I like github in lots of ways, pull requests, a lot of stuff on top of git
... what W3C gives you is persistence for history, so you can go back and check
... we have the CVS record
... we can see what happened, who changed things etc
... at the moment all that is within w3.org
... we have comma tools and so on

wycats_: why don't we have that with github?

timbl: W3C has a persistence guarantee

annevk: you can clone the git

timbl: we could every night sync onto w3c space

dka_: including the commit history

timbl: the problem is that if you use the github tools like issues etc then it doesn't include that history
... anything that's decentralised, I'm happy to use whatever tools we like
... I'm worried about tracker, the messaging

wycats_: the pull request feature is the most problematic part

plinss: the CSS WG mirrors our repositories onto github
... we don't use issue trackers
... our test suites and our drafts are on github
... the canonical source is Mercurial on W3C space
... we have git and hg versions of both repos
... I'd propose we do the same thing
... using the github collaboration for pull requests and so on
... github have APIs for those
... we can use those to pull out that data
... I'm syncing all the issues etc for 'Shepherd' from github

<annevk> Everyone should be added to the owners of the w3ctag thing now except for ht. Could not find ht on GitHub.

<ht> I should be there. . .

<ht> Hang on

timbl: I'd love to see the issues etc be written out into a standard format

plinss: we can capture all that data and keep our own archive of it
... I like the social part of github, I'm not comfortable to rely on them for our storage

dka_: the question I asked was about what happens when HP buys github
... we need to have a story for that

plinss: we can't rely on that

annevk: the most important information is in the repo, not the issue tracker
... the issue tracker should be a thing you can lose

timbl: issue tracker history is interesting

noah: one of the things to watch about the TAG is how long it runs relative to how quickly its membership turns over
... the TAG has a long term presence, and the same issues come up after 8/10 years
... some combination of minutes/action etc needs to be captured

timbl: CSS predates the TAG

dka_: Yehuda, you started to articulate a story about this

wycats_: when whytheluckystiff nuked himself, people managed to reconstruct almost all his work through local copies
... you tend to be able to reconstruct content

<annevk> noah, do you have GitHub account, and if so, should I add you to the repo?

<annevk> (everyone else is added)

timbl: how do people feel about using Google Docs?

dka_: I'd use it for an agenda for example, but not for anything else

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
... people think of large companies with a monopoly, like github, as being problematic because of putting all their eggs in one basket

dka_: I think it makes sense to mirror what the CSS WG is doing, to make sure we mirror content
... I expect W3C to be around in 50 years

noah: are you saying that documents should be referenced through w3.org?

dka_: yes

noah: you're taking the gamble that w3c will make the investment of rescuing stuff to rehost our stuff that's in github

dka_: it'll already be done because it'll be a clone

noah: github has a collaborative model, whereas W3C work has IP commitments
... we expect email without IP commitments, for example
... but core work needs to be under those commitments

wycats_: you need a click-through CLA (usually hosted by Google forms) and you don't accept pull requests without people having completing that

marcosc: in github you can have a contributing file that requires you to agree before committing

<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]

plinss: in the test suite repos, the click-through you have to sign is a W3C form
... and the counsels are ok with that
... before you accept a pull request, you have to check that people have signed it

noah: so you have to do some manual due diligence

dka_: that's true anyway, if people post to W3C mailing list

<wycats_> try curl https://api.github.com/repos/wycats/handlebars.js/pulls

Yves: before you can post to the mailing lists, you have to agree to IP commitments
... we can have the same thing for pull requests

ht: I'm more familiar with Mercurial than github
... it's good for me if I can use Mercurial
... I'm not sure that I've heard about how things get auto-published to W3C space
... if I want to create a document in W3C space today, I can use CVS and just commit it in and it appears

<wycats_> http://hg-git.github.io/

<annevk> http://www.w3.org/2002/09/aa/ does not say anything about licenses Yves

<Yves> hum, I'm pretty sure there was something for contributed text, I'll check

<darobin> [also see http://www.clahub.com/]

annevk: we can do that too, with a commit hook

<annevk> we would really

timbl: can you make a commit hook on github to ping somewhere else?

wycats_: yes, you can receive anything that happens on a repo

timbl: we'd like a piece of W3C space that is automatically synced

plinss: we're doing that in CSS WG

<darobin> [we use hooks extensively to publish the web-platform-test to w3c-test.org, to push ReSpec releases to w3.org, etc.]

timbl: one of the things I like about W3C is that the basic URI is the thing that everyone sees
... you've got ,cvs, ,log etc
... encrusted URIs for views of the repository, but the pure URI is the clean URI
... in github the default URI is the under-the-covers URI

plinss: we can set up both views
... we can add the comma operators

timbl: we can do that in the htaccess, yes

plinss: we can have all of what we have with CVS with a git and mercurial system
... it takes a little bit of glue but we can do it

timbl: people will end up referring to the github version

<noah> I thought Yehuda said: "Published spec XXX says MUST" which one?

plinss: some of the WGs live around the hg repos

<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

plinss: in CSS we're very careful to use the w3.org URIs
... we'll have to do the same thing here

marcosc: in an ideal world, all this stuff would work, I don't think it's difficult to get this sorted

<annevk> (git syncing is being worked on by systeam)

marcosc: 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

wycats_: I'm happy to do that

annevk: I've added people except noah

noah: I need to get a userid on github

marcosc: when stuff starts happening on github, they can follow repos etc
... we don't have a paid account
... so can't have a private repo
... we need to sort out some logistics to manage that

dka_: for each piece of work we have a repo
... there's work to be done in writing these scripts

plinss: I'll do that

annevk: I have scripts for the WhatWG specs

plinss: one more thing, we could be using the w3c organisation rather than w3ctag

annevk: I discussed with darobin, but it's easier this way because we can create repos as we like

dka_: can we get W3C to pay for the repo?

annevk: WhatWG got it for free

dka_: so we can pull rank?

annevk: if you email them you can get it

marcosc: we already have people who are paying members

annevk: shall I email them?

dka_: yes
... noah has a corollary issue about product pages

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
... my answer to that was HTML pages
... because the tools weren't flexible enough for anything else
... and then we have a roll-up page which is like a dashboard for the TAG

<darobin> [note that w3c already has access to private repos, so you can reuse that if needed]

noah: this is for helping to keep track of the goals and focusing discussion
... 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

wycats_: is the infrastructure in the repo sufficient?

noah: it doesn't give the community information about the goals

dka_: we could use a README file
... in the repo

timbl: all those documents can be stored in a repo

wycats_: README is special in github, it's rendered and displayed in the repo

noah: it's useful having a dashboard page

JeniT: the list of repos gives a dashboard

noah: needs to be accessible to AC members

<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

JeniT: we need some social conventions about what needs to go in the READMEs for those to work

noah: I tried not to let tools be an excuse for doing a crappy job

dka_: we've only talked about incorporating github into our operations
... we haven't talked about minutes for example
... plinss and I have discussed that automatic minute taking is extremely useful

<wycats_> fwiw: https://github.com/rwldrn/tc39-notes

<wycats_> for example: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-05/may-21.md

ht: we already have a two-track story about that
... the vanilla minutes come out in W3C date space
... the cleaned up approved minutes go into TAG space
... that step could move into git-managed TAG space
... if we're ready to do that

<wycats_> actually they've gotten better: https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-03/mar-12.md

noah: with CVS we can do a grep over 10 years of minutes

plinss: we can take a copy of the older minutes
... we can map the URIs

dka_: we need to figure out how we do that
... personally I'd like to see minute taking and cleanup be easier than it has been
... it felt difficult to clean up minutes when I was in the TAG

ht: it's a pain but it's worth it

dka_: the mechanics are hard, not the intellectual effort

noah: linking imagines in the minutes are helpful

Yves: it should be easy to import CVS history into github

noah: how do you want this round of minutes done?

dka_: as we have been

plinss: we're not changing things now

dka_: we're going to have Siri auto-generate them

plinss: we've talked about using github
... we also have the TAG blog, wiki and twitter account
... we need to be using these tools too
... we need to categorise when we use these

wycats_: github is sort of like a wiki
... you can use it like a wiki
... you can 'Edit' the READMEs
... if there's a strong reason not to use github for agendas, fine

slightlyoff: TC39 is moving to using github

dka_: we do have the TAG wiki in W3C space

plinss: there are advantages to using the tools in W3C space

timbl: we've talked about just taking all CVS into git

<noah> scribenick: noah

tbl: Possible lunch discussion: moving all of W3C Web site to git. Would obviously need to coordinate with systems team.
... would love to have more flexible way of updating on planes

pl: OK, but over lunch
... we have a blog
... appropriate to use it for certain things
... quick response, high level overview
... e.g. first crack at futures could be in the blog, or could announce larger docs in the blog, then tweet.

dka: BREAK for lunch

Web Audio

We are joined in this session by Oliver Thereaux from the BBC

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.
... 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.

OT: I'll update you on two things 1) what the Web Audio group is doing and 2) how it got there.
... 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.
... 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.
... So, there's class about the level of specificity that's most helpful in the specs.

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.

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.
... We're bringing to the Web an industry that's traditionally depended on massive precision and performance. Occasionally, the problems are more than perception.
... So far, "architectural" decisions have played a small role in the design of the APIs.
... 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.
... We are in the process of bridging all those to the Web platform.
... In a way, doing midi in the audio wg is partly an accident, tracing to traditional use of midi for music
... There were attempts to use <audio> tags and Javascript.
... Mozilla had a proposal. Then another proposal was media stream processing, plus one from Google called Web Audio API.
... 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.
... The stream option pretty much gave the stream to the Javascript to munge on.
... Had not been fully implemented, but there were partial implementations in Firefox nightlies, etc.
... 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.
... 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.

DKA: So it's a conceptual model?

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.

OT: Right.

TBL: Explain again please, what's the difference?

OT: The streams stuff does less, but is easy to build and ship.
... Javascript libraries would have been built, perhaps using a model like JQuery.
... In the end, the Web Audio API was chosen not entirely on merit. There was discussion of many perspectives.

YK: What about exposing several levels.

OT: Thought about it, but there's no clear right answer. This had a lot of buyin.

MC: Determined how?

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.

NM: In Web Audio, you can do your own blocks?

OT: Yes, but it's really complicated almost to the point of being broken. You connect the blocks. There is one generic Javascript blocks.

NM: You can do your own native blocks or your own Javascript blocks?
... 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?

OT: Um, no.

NM: I'm surprised.

AR: Why is there a latency problem with Javascript

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.

AR: Why not do the same thing for the Javascript

OT: Not sure.
... The supplied building blocks cover 99% of cases. They've been used for years in hardware and software.
... 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.
... 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.

HT: What about text to speech.

OT: Ah, I should have mentioned that most nodes do processing, but some do synthesis.

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.
... 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.

OT: I'm pretty sure you can do text-to-speech
... 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.
... 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.

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.

OT: There's a cost to that layering. You can't optimize across.

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.

See Watson and Mamrak, Gaining efficiency in transport services by appropriate design and implementation choices dl.acm.org/citation.cfm?id=13677.13678

YK: Transferrables help

AR: It's really good if the APIs feel like natural Javascript APIs, even if the implementation is native, tricky, and highly optimized
... It also let's people do test implementations in Javascript.

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.

OT: Yes

AR: Does scrubbing work?

OT: Yes, just start playing the middle of a buffer

MC: The <audio> tag is mentioned in the spec?

Someone: as source or target

MC: Hmm

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.
... ...and video. There are real benefits.

OT: That makes some sense.

YK: Would tend to make it more composable with <video> tag, WEB RTC, etc.

AR: The <audio> element is owned by the HTML WG, and has an API. I >think< this could be desugared into the Audio API?

YK: You probably should do for more of them.

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?

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.

AVK: Clarify, the prefix is only on the constructor.

YK: The general way the platform deals with this is not to standardize the non-standard forms.

We are discussing: http://www.w3.org/TR/webaudio/#deprecation-section

Lots of pro/con discussion of how bad this really is and what the precedents are

MC: I was confused and annoyed.

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.

MC: It adds to surface area of API>

NM: We've heard from OT that the group really felt they needed to keep the old duplicate names.

OT: Indeed, we tried dropping them and 5 mins later the complaints had convinced us to change.

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.

OT: We at first thought supporting all of it would be really painful, now we're seeing it as not so painful.

YK: OK, but why standardize it?

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.

OT: In our case, it's only the names that are different.

PL: We have exactly the same thing in CSS

OT: Do you keep an informal reference

PL: Maybe a non-normative note

AR: Maybe you can prove to yourself someday to drop it.

TBL: Do you warn or deprecate?

AR: Sometimes
... Leaving it in the spec increases use

NM: Yesterday we heard that as things evolve from experimental to production, the function changes. This is a counter-example.

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.

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.

AVK: I suspect Mozilla felt that if the Web depends on it, it should be documented.

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.

YK: The percentages of the Web we're talking about here.

MC: The audio specification describes what's in Webkit. The question is how the content got into the Web.

YK: We should have an agenda item.

OT: The interesting thing is that we used prefixes and it didn't help.

HT: As it didn't for x- media types

NM: So, I remain a bit suspicious that the story we heard yesterday that uses hyphenated names might also prove to lead to problems.

AR: I think it's different, because it comes from user code.

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

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".

HT: Yes, if we were to formally disagree, we would have to back that with evidence
... 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.

AR: You could make it non-normative without affecting implementors at all.
... Eventually, market developments could lead to removal.
... It's also not clear early adoption is sufficient to be worth preserving the compatibility

HT: Possible proposal from the TAG: "Move them to non-normative appendix, acknowledging that it's a change"

NM: yes

OT: What if someone follows only normative spec, they find they don't support some apps.

<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

HT: you can't prevent those
... they happen

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.

DKA: I'd like to limit the discussions to issues around audio.

HT: I made a proposal. I'd like to either develop wording for a proposal, or punt.

YK: I'd like to put an agenda item up for another time to discuss the general problem.

AR: I think there are several other related things worth discussing.

HT: Having the concrete example has been helpful.

AR: There are a set of specific issues as to whether the APIs are idiomatic, connections to html elements, etc.

YK: Are you the person with whom to speak (laughter)

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...
... Do it early rather than late.

TBL: By, it's been out there a long time do people mean you've been at it in the group for a long.

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"

MC: Well, this feels less like the TAG's story. We're looking for a clean, orthogonal Web.

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.

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.

<timbl> "This page best viewed with ... the developer mode on"

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.

PL: Yes. There's no one right answer for all scenarios.

AR: I'm hoping WGs are attempting to be data-driven. In Webkit etc we could get usage histograms.

OT: We have such data, and do drop things with low use. It's all relative. We have 100s where CSS has millions.

DKA: About to take a break

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.

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.

YK: Everyone knew 2 years ago it was broken

OT: But lately it's perceived as a standard

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.

OT: Well, I personally am not hard over that it be normative. Maybe we could bring that back to the group.

MC: That would be good, as we're worried about precedent.

DKA: Thank you so much for coming. Having you here in person is very helpful and very much appreciated.

YK: I don't think we're advocating for breaking existing standards.

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.

<dka_> ACTION: Yehuda to send a note to the web audio working group with some architectural suggestions. [recorded in http://www.w3.org/2013/05/30-tagmem-minutes.html#action01]

<trackbot> Created ACTION-811 - Send a note to the web audio working group with some architectural suggestions. [on Yehuda Katz - due 2013-06-06].

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.

WE ARE ON BREAK FOR BIRTHDAY CAKE

System Applications

<marcosc> https://github.com/sysapps/

<marcosc> WG link: http://www.w3.org/2012/sysapps/

DKA: We'll check whether Mounir Lamouri can join us for this session. He is co-chair of the sys apps working group.

MC: What's good for the TAG here?

DKA: Maybe from an API design perspective. Also where the group sits, updates on controversies, etc.

MC: http://www.w3.org/2012/sysapps/#roadmap has lists of deliverables. Manifests were transferred to Web Apps on 21 May 2013
... App URI stuff is in the same space as the old Widget URI stuff
... Scheduler allows apps to be descheduled and wake up. (Scribe thinks others are self-explanatory)

HT: How would I know whether some new API I wanted to build to into Sysapps vs Web Apps

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?)
... Admittedly a bit odd for someone building the Web platform

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 ..."

NM: Well, to which code are they exposed?

Several: typically, to certified apps.

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.

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.
... For example we've taken a quick check on use of futures, and we're prototyping at the same time.
... Process is very open, doing all work on Git Hub

DKA: Maybe we should review some particular features. E.g. there's confusion about Web Sockets vs. Raw sockets

MC: Web Sockets checks all sorts of headers to enforce security. Raw sockets are just that. You can do, e.g. an IMap connection.

ML: Some range of ports is available to packaged apps.

MC: Not sure that's in the spec yet. Not much is yet explained about security details.

ML: Sometimes issue discussions happen on Git Hub and aren't visible enough to the wider community that follows the e-mail list.

MC: Similar issues may come up if the TAG moves toward Git Hub

YK: Some advice: when people collaborate, some people want feedback, but that doesn't work as well as collaboration.

<annevk> (261 subscribers)

NM: Some concern about whether this will work for TAG members who depend on email

AR: You can rig Git Hub to send emails

<slightlyoff> noah: to clarify, I was saying that GH sends mail to participants in threads, and that users can subscribe to repositories

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.

AVK: I thought this session would be more on...I thought this was more going to be on packaged apps.

Several: we have a later agenda item for that.

AVK: Oh, OK. Either way.

DKA: If you want to have the assumption that you want to build the dialer using the Web...

YK: Don't call that the Web

DKA: Well, that raises the important question of what the Web is.

YK: Not happy if that means only discussing downloadable packaged apps.

AR: I'm happy with how things are going.

DKA: The Firefox OS and Tizen communities are collaborating. Do we know about Chrome OS.

ML: They're saying maybe someday

YK: Well, they're doing their own chrome.* APIs.

AR: I'm not sympathetic

ML: I think it's not so bad. It's at least a useful experiment.

YK: There's a general API review question, but a repeating concern is access to only one device/sensor/etc. at a time.

MC: I've been working with Rick Waldron on that

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

Packaged Apps

ML: In Firefox OS we have hosted apps which have only hosted apps, which have almost no priviledge...

DKA: Is there a difference between that and something I visit on the Web?

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.

AVK: Also, gets it's own cache context

<annevk> following a link will launch the browser app (long term plan)

NM: Has download for more than the page itself?

MC: Uses the regular appcache
... ..shows examole... with, for example, "appcache_path": "/cache.manifest"

The manifest appears to be JSON

NM and AR: Do you get FWD/BACK

YK: Not in the usual sense, but you can use the history APIs

ML: All the things like cookies, cache, etc. are in isolated contexts from other apps

AR: If I've previously browsed to facebook.com and authorized, then go to the downloaded app, do my authorizations carry over?

ML: No

DKA: could be problematic for o-auth

MC: The CSP defaults are not changed, but you can narrow them.

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?

MC: Yes, in the same way as Web today. Relying on CORS and RESTful APIs on the server.

TBL: So, I can give it raw socket app?

NM: That's not this class of app.

TBL: Is it in the install sequence?

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.

TBL: You could do things with signed manifests, though people gave up on that. Anyway, so you have to go through the marketplace.
... Are there multiple marketplaces?

ML: No.

NM: I think that's a Firefox OS answer, not an API answer, right?

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.

TBL: Interesting, but not where I was going.
... 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.
... Can I rebuild iTunes. Now I have to go through SteveJobs/Firefox-central to be allowed to do it?

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.
... We do want to make sure only trusted apps are trusted.

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.

ML: So, we currently trust only our own.

TBL: Saying you can do it by hacking it isn't satisfying for non-hackers
... I want to set up my family with more than one marketplace. I think they're all trustworthy.

YK: I think Mozilla's view is they want to have this control over security issues.

ML: More subtle than that. We need a good security story around some APIs, so we restrict them to packaged apps.

TBL: That's my issue. I'm not asking why can't I have a Web app in my store.

YK: I think the goal is that control fo

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.

AR: This is the same question as cert authorities. People have distributed across their systems (artifacts supporting) contracts we've agreed on.

NM: I think Tim wants to register.

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)

ML: What you've just described I would like to see. Our time is limited.
... I'm trying to get people at Mozilla to "force trust as package". We might want to trust Google not to do evil things.

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.

TBL: I agree. Whether it happens to be zipped or manifested should be orthogonal to the trust issue.

YK: I heard yesterday it has to be packaged.

ML: The reasons both Mozilla and Google are doing this include that offline storage is a mess at the moment.

TBL: That's temporary.

ML: Also, some developers like the ease of zipping up.

TBL: I want to go back to the trust issue.

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.

[scribe missed something]

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.

<annevk> but but but I don't want stores

<annevk> the whole store model is so much copied from Apple and very much anti-web

<annevk> I don't understand why it's taken as given

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)
... I want to be able to set these up.

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.
... Ultimately you need to swap the root of trust.

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.

YK: The question is, do we want to find a way to let Web apps have these permissions.

TBL: I know you want that, but I want just now to discuss supporting multiple app stores.

AVK: But that's just copying Apple's model

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.
... 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.

TBL: It's not hard, it's dangerous.

YK: Either you download or you write all the apps yourself.

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.
... It need not be dominated by one.

YL: The app store is giving you an annotation that says the code is safe.
... If you replace that by a company on their own Web site, you have the same thing more distributed.

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.

YK: I think continually looking at the App Store model isn't useful.

DKA: Are app stores and central authorities really the same?

<Yves> App Stores are just an implementation artefact

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

YK: Does it have network permissions?

DKA: Let's assume that it does.

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.
... 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.
... There's a question about interaction of domains that's the core of the security question, and that we can tease apart.

YK: My thinking is that packaged apps are a quick approach to getting them into the platform.

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.

YK: Playing those tricks it's difficult to get the edge caess.

ML: Android and Firefox OS both pattern match on URIs and will open certain prefixes in installed apps.

NM: What he's saying is that historically, the mediation between apps is in the os.

AVK: My vision is a URI bar everywhere.

TBL: What ft.co wants to do is they want to download the paper for today. They want to be able to intercept.

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.

YK: I think Anne says there's a gap between packged and apps and URIs

ML: Please stop talking about packaged apps.

YK: We do you need a Web activity for a hosted app

ML: You need to know whether to open the browser.

AR: App wants to say: please route bits of this URI space to me.
... 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.

NM: I like AR's view of this.

AVK: Your model is of a typical os with apps etc.

AR: I'm not saying that.

AVK: You are phrasing it as an app.

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.
... A completely virtual space generated by Javascript.
... 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.
... Yehuda, that's what I want.

AVK: We should have that in a year, but without an app.
... "you don't need an app for that"

YK: My concern is that there are fiddly details that may make this hard in practice

TBL: We've agreed there's a need to distinguish pages to which you've given trust, and those you haven't

ML: Right, but in other respects, a hosted app and a Web page are the same thing

AVK: Facebook.com will be different from the hosted app

YK: The problem is if most people feel they have to implement everything twice

TBL: I think there's a fear you're trying to get at, but you haven't expressed it well

DKA: are we at point of diminishing returns? There's been good insight, but not clear output.

TBL: On board are five things to keep separate.

<JeniT> timbl's notes from the board

<JeniT> * multiple stores/keys vs single

<JeniT> * ultimate control user | mozilla/chrome/apple/sony | vodaphone/orange

<JeniT> * packaged apps vs web apps

<JeniT> * prohibited vs cordoned-off vs allowed

<JeniT> * issue of linking to stuff in app: space vs http:

F2F

DKA: We had agreed 13-15 October. Now we find that Tim as well as Yehuda can't make it

TBL: How about 1-3 October?

General agreement.

TC 39 is Sept 24-26

in Boston

YK: Even a day earlier Mon-Wed is better

TBL: I can definitely do 1-3 Oct, and probably could do 30 Sept through 2 Oct.

AR: 30% chance I can't make it, won't know for a month

DKA: need to check with Henry

Marcos, Yves, Dan, Anne, Peter, Yehuda and Noah (if needed) are all OK

ADJOURNED

Summary of Action Items

[NEW] ACTION: Yehuda to send a note to the web audio working group with some architectural suggestions. [recorded in http://www.w3.org/2013/05/30-tagmem-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013/06/18 13:37:33 $