SysApps Face-to-Face #2 -- 28 Aug 2013

<timeless> Scribe: Josh_Soref

<timeless> ScribeNick: timeless

Agenda

wonsuk: good morning
... first we'll talk about Telephony, zkis will lead the discussion
... after that, we'll talk about generic API Design issues
... and then we'll probably split the group before having lunch
... does anyone have comments on that?

zkis: could we ask which people are interested in that?

mounir: we should discuss groups before lunch

Telephony

<thinker> Prsent+ KueiFong_Lee

zkis: we won't discuss using System Messages / Factory objects
... i'd like to discuss how we deal w/ Telephony Services (CDMA...)
... the rest of the details can be discussed offline

<wonsuk> Web Telephony API

<wonsuk> left issues: https://github.com/sysapps/telephony/issues

zkis: telephony is based on standards
... the standards are implemented by modems
... with varying command sets
... and there are also sim cards
... The Ofono stack has the best handling of modems
... i wanted to show its API set

<room> http://git.kernel.org/cgit/network/ofono/ofono.git/tree/doc/modem-api.txt

zkis: one of the interfaces is voice call
... trying to map all of these things into a dialer is quite difficult
... the Web Telephony API is trying to do a simple mapping
... it assumes you have a modem, and the modem is online
... if we don't have a telephony object on navigator, then the modem isn't available
... when we dial out, there's a serviceId to be used
... it's roughly a subscriber ID + service itself
... a SIM card is a Subscriber identity module
... in combination with a service, like Telefonica
... they represent a service
... the serviceID is a unique identifier
... the problem with this approach is that it doesn't provide any means to use other functionality present in Telephony
... when we do Network API or SIM API
... it would have to be done on a different Navigator object
... maybe instead of presenting [string] IDs, we could present Telephony Service objects

<room> zkis API proposal

[ zkis projects API proposal ]

zkis: service, provider, displayName, method for dialing, sending tones, getting calls
... you could have a call active, and receive another call
... you might be talking w/ a telephone
... and reject Skype calls

gmandyam: on the 1x call in Verizon, the Skype calls are over the service switched path

zkis: you could set Skype up a port for IP
... as well as circuit switched
... -- but, this is about a policy

gmandyam: you need data concurrency
... but CDMA blocks

zkis: since we have the capability to support both types of policies
... this isn't an argument for it
... but this solves it
... it also solves differences in protocols
... it also presents SIM info, telephony, network
... on TelephonyManager, we have a handler for incoming calls
... and also on the service

gmandyam: can you go down to conference call handling?

zkis: conference call handling is the same, but it's on a different service

gmandyam: in the old system you called join() which returned a conference call

zkis: yes, it's the same here
... but it's differently for VOIP
... we discussed conference calls in a one-on-one meeting
... i raised issues on it

anssik: zkis, which options makes the common UC simple
... while allowing for complex UCs
... if you want to make a web app to implement the common UC

zkis: the old approach is simpler to use for people who don't care about telephony services
... and assume there's a service available

anssik: you're saying the common use

zkis: i'm saying we could have an object representing the service
... but the problem with the old approach is that there could be no service available
... you want to dial
... and there's no indication that there's no service
... it has problems on the error path handling
... another option is TelephonyManager is a default telephony service
... but then your object could change

anssik: how common is it that it changes?

marcosc: someone pops out the sim

anssik: could we just have "things are broken"

marcosc: zkis was saying that the error handling path
... dialing is a top level thing which assumes a default service available
... which may or may not be true
... not having navigator.telephonyManager being a service is a problem
... there are advantages/disadvantages to either approach
... 90% of the time there's a sim, and it's a phone, so it can dial 911/112
... you could mix/shift things around
... it's not that hard
... but for more advanced UCs, you might want to access SIM
... it gets kind of funky
... i don't know what access to the telephony service itself allows

zkis: i think it would makes sense to depict the developer flow
... when you write a dialer flow
... you need to handle PIN query
... and you need to handle Emergency calling
... in Dialer, it's in contextual
... it may be a Phone Number, and MMI string, an USSD, or an Emergency Number
... based on what the user is typing, the UI may [need to] change
... these all pretty much complicate the dialer
... we try to make it easy for alternative dialers

anssik: you're an expert in Ofono
... do you know how it looks on Android?

zkis: yes

anssik: what's the API?

zkis: it's very low level
... it exposes GSM/CDMA

anssik: what type of third party apps are people building?

zkis: there's no problem for Android developers to use them
... the assumption is that Operators or people in the Telephony business are writing them
... we don't expect to have 1000 dialer apps on a store

anssik: exactly
... so the target audience isn't millions of developers

zkis: that's my understanding
... and the experience on Android
... i wouldn't be afraid of exposing low level functionality in a way that makes sense
... that the application needs to check the services available first
... isn't a problem

anssik: so the target audience is a very specialized group of people who know this in and out
... going lower level rather than higher level seems reasonable
... OTOH, if the api is for typical developers, then it makes sense to expose something simpler

zkis: the idea was that keeping the API simple would allow more people to write dialers
... but if we had service objects, then people could write more complicated apps
... we could have a method to get a serviceObject by ID

hsinyi: the ED proposal is simple and easy to use
... but to provide more complicated apps
... Mozilla has ICC API, and Pin Lock APIs

zkis: where do you provide those?

hsinyi: separate objects on navigator
... and operator API
... with this api, it isn't a problem to create complicated apps

zkis: it looks like a hack
... starting with how modems are designed and how the radio is designed

hsinyi: if you want to look into the modem
... then a separate ICC
... In SMS/MMS, you need this functionality
... having a separate functionality
... reduces redundancy

zkis: you only handle part of the problem
... you can't handle SMS via LTE-IP or Circuit-Switched
... a telephony service can handle that
... how do you know if you have telephony functionality at all
... it could be a Tablet
... this handles everything
... i think the Mozilla API is built based on different UCs
... I see a lack of design
... you're adding interfaces as you meet problems
... it wasn't designed properly from the start
... this API is integrated and it handles all the UCs in Telephony

hsinyi: I agree that decision
... with all the bits in an api, it's for experienced developers
... but with separate things, we can make simple apis which basic developers can use

[ chatter between zkis and hsinyi ]

zkis: how simple would it be to have a single structure which handles all of these?
... CDMA service, GSMA service, Skype service, SIP service

hsinyi: i'd like to have other members comment on this
... after talking w/ sicking
... and thinking
... maybe we can provide another way

zkis: [do?] we want to provide an API that maps along the existing system
... i wouldn't want to let Telephony correctness out of the picture
... developers understand Telephony

jungkees: a question about the Telephony Event interface
... to receive an incoming call
... the event is driven from a dom event
... so the telephony app needs to be running
... why not use system messages?
... so the telephony app
... gets the call
... is that a possibility?

zkis: we have an issue about it
... in all the phones i've dealt w/, the dialer is a prestarted application

jungkees: with native, we don't actually have a running call
... we push it up and run it

zkis: otoh, we have to guarantee that you can answer the call
... we need an upper bound limit on time to start the app and answer the call
... UI coming up, you press a call
... system messages don't solve that problem

Josh_Soref: +1

gmandyam: what's been added to enable IP Telephony?
... i think we have too many efforts to enable IP Telephony in the browser

[ gmandyam enumerates places where people are trying to integrate IP Telephony - W3C, 3GPP, IETF ]

gmandyam: i'm not convinced we need to bundle that functionality into this api
... what in your proposal is being added to accommodate IP Telephony

zkis: this isn't adding specific things to work with IP Telephony
... except an interface for Conference Call
... a service represents a SIP account or SIM-based account
... except SIM based has services
... for GSM, we may have a cellular service which implements telephony
... which has sim settings, telephony network, call forwarding
... but they might not be there in SIP

gmandyam: i can see that this proposal is better than the current draft
... for CDMA/GSM
... but for implementation/testing
... we'd have to verify that this works for SIP stacks
... i think that's unnecessarily burdensome
... VoLTE is SIP
... but you build that into the stack

zkis: you could do IMS with WebRTC
... you could expose that service through this API

gmandyam: an implementer could do a valid implementation w/o VoLTE SIP based

zkis: if an implementer provides extra bits
... then it has to document it
... now we're talking about a voice call interface

gmandyam: with BREW
... We called it ITAPI
... but CDMA's teleconference model made the system complicated
... because it imposes constraints

zkis: call state management is different for CDMA
... you can't guarantee call state with CDMA

gmandyam: yes, dialing is strange

zkis: it's a pity we don't have anyone from AT&T here
... i think we still need to convince Mozilla
... but i'm open to discussing to work on a usable API

marcosc: it's kind of hard to make a call-in
... until we looked into it in more detail

<gmandyam> Will clarify my comments: in previous experience w/BREW OS, we tried to develop a common TAPI (telephony API) for GSM/UMTS/CDMA. Conf. call for CDMA however had to be handled by app-layer logic. Zoltan's proposal tries to branch off the returned objects based on protocol, which will make development easier.

marcosc: this [Etherpad] doesn't look really wrong
... it seems to make sense
... i'm fairly convinced that we need a cellular service object from previous discussions
... i don't have an issue with adding this thing

zkis: we could do an example of how the development flow goes with both apis
... checking a few things in a dialer app when you start up, isn't a big deal.. 2-5 lines of code

<Zakim> dsr, you wanted to ask about simple use case

dsr: on my android phone, i have multiple dialers
... passing in a URI: tel: or sip:
... i imagine the user is asked which thing to use
... i might have multiple SIP services, multiple sim cards

marcosc: we have an issue for that
... this API intersects

<room> Describe the relationship to tel:

https://f.cloud.github.com/assets/870154/690783/c2049176-db35-11e2-889f-6799df31e59c.png

mounir: in Firefox OS, we have Web Activities
... for tel:, sms:,
... we use Web Activities
... which lets the User choose

dsr: if i'm on wifi and i want to use a cheaper calling system (Skype)
... how does a user get to make that choice

mounir: Skype and built-in-dialer would be registered for the "dial" activity
... you click dial and and get something like that

zkis: or someone implements a dialer which lets you ask which service you want to use on dialing out

dsr: so we have the opportunity to customize the UI for that

[ Maemo and BlackBerry let you pick the outbound service from the dialer UI ]

[ zkis reads through an issue list ]

gmandyam: a lot of these states don't matter
... i can't even fathom UCs for them

anssik: these are from GSM

zkis: these are from GSM/CDMA
... some aren't mandatory

anssik: are there UCs for all of them?

zkis: we had a two month discussion on this
... i was of the opinion that w shouldn't map the states
... because it isn't guaranteed to happen
... <ril.h> -- radio interface layer
... my opinion is that we only expose state change with parameters defining state
... and a possible state name change
... you need a lot of these
... even GSM networks which have these states
... sometimes they're skipped
... but it was hard to convince dialer developers that the network doesn't provide a fixed state machine
... we have a depiction, but it isn't guaranteed

<room> http://www.w3.org/2012/sysapps/telephony/images/inbound_call_state_diagram.gif

<room> http://www.w3.org/2012/sysapps/telephony/images/outbound_call_state_diagram.gif

zkis: these are expected order, they happen 90% of the time

<gmandyam> To summarize, in the existing Call State enum, there are several states defined that I don't believe are even exposed through the typical Radio Interface Layer (ril). I believe the enum should be simplified to the minimum no. of states exposed for GSM/CDMA based on the ril.

marcosc: "all diagrams are non-normative"

wonsuk: i think we have a lot of issues
... we'll have a detailed discussion in the afternoon session

zkis: there was a discussion about using constructors

<wonsuk> Evaluate spec for use of Promises

zkis: i argue that on success and error we return a telephony call
... it isn't a simple success/failure
... you can't have a telephony call w/o a telephony service

marcosc: you're correct that you need it
... but idiomatically, you can abstract it away
... in terms of objects and behaviors
... anyone can pull the service out at any moment
... the service could go away
... you create the object, then start the dialing process
... what you're saying makes sense
... but idiomatically, it feels cleaner to make the object and then start dialing
... you're saying you could make objects and never use them
... but it's idiomatically to create an object

gmandyam: should the api recognize airplane mode?

marcosc: airplane mode would be detected at dial()

zkis: promises handle one end result
... if you disconnect
... you expect a disconnect reason

gmandyam: say you Land (flight)
... you get authentication
... initially Emergency
... then Roaming
... then Home network
... first call fails
... that promise gets invoked
... you need some indication to the user as to why it failed
... is that a true error condition?

zkis: you're dialing, it goes to network
... it establishes a voice channel and goes to voice mail
... you can't handle that with promises
... you have to handle that with state management

[ marcosc points to https://github.com/sysapps/telephony/issues/17#issuecomment-20193354 ]

zkis: you don't know if there's a real call, or a junk object
... there's no telephony object in the network

gmandyam: during the last F2F
... didn't sicking say some methods were synchronous?

marcosc: it turns out these are asynchronous

zkis: if you can do a promises proposal, make a branch

marcosc: we've wasted a ton of cycles on this
... you've made a bunch of points
... but the idiomatic design
... you have a point about dependency of the service
... you can keep dead objects around
... after you hang up a call
... so you're asking for getCalls()
... you wouldn't
... you'll only return active ones
... there are issues w/ garbage collected objects

zkis: one idiom shouldn't be applied everywhere
... you have to prove it works in telephony

marcosc: we could try to do that

gmandyam: you'd need to talk about the dead object UC
... when you trigger GC

anssik: below marcosc, i commented about testing this on real JS developers
... but this API won't get much exposure amongst the developer community
... marcosc, do you think this consistency with the rest of the platform is important
... i understand the case if the api would be used by all web developers

marcosc: not really
... it's not that important
... but it sets a precedent we're trying to move away from
... we can keep it, but try to discourage future apis

anssik: that's a good point

marcosc: we're seeing the same patterns through most of SysApps

gmandyam: and WebRTC

marcosc: the TAG had a call and it got very heated

zkis: the issue is still alive

marcosc: let's close it
... forget promises
... Factor or Constructor

zkis: Promises with multiple outcomes

marcosc: that's not going to happen
... the weirdness is that you don't ...
... there's magic behind the API

zkis: we need to give an example of the development flow

marcosc: we have some examples in the spec

<anssik> +1 on writing more examples

zkis: i'm ok with leaving this open

marcosc: so we won't do Constructor... we'll keep the factory
... I promise to add more examples

[ scribe notes that there's only one example and it's virtually useless ]

zkis: mozilla seems to prefer the old way
... gmandyam thinks the service would help solve problems
... i still expect input on this

[ Break ]

<marcosc> Scribe: Marcos

<marcosc> Scribnick: marcosc

API Design

<marcosc> zkis: I wanted to get feedback on how to deal with dynamically appearing/disappearing objects in an API. How do we signal those changes?

<marcosc> zkis: I wanted to ask for feedback about how we deal with signalling this. Do we use a sequence and an event?

<marcosc> marcosc: which example in particular are we talking about?

<marcosc> zkis: let's take the telephony API

<marcosc> zkis: we have an array of calls, for example

<marcosc> ... marcos describes "the loop" in the browser and why using arrays and objects that reflect states in a system in real time can be a problem... this can lead to race conditions. Using a sequence is a trade off in that it gives you a snapshot of the state of some system as some moment in time. This has tradeoffs that need to be considered on an case by case basis.

<anssik> ScribeNick: anssik

[mascosc explains how task queues are spec'd in HTML5]

marcosc: signaling happens at the start of the script exec
... in practice, does not have an effect on developers
... ES 7 will define the event loop
... now it's in HTML5 spec
... at least, on TODO list for ES 7

<room> https://github.com/sysapps/telephony/issues/81

<wonsuk> Title of this: Dynamically changing arrays could lead to race conditions

zkis: race conditions are a generic issue that needs to be resolved, for example see Telephony issue #81

marcosc: generic pattern is as follows, use array when it's going to be static or only part of the loop, if mapping to subset you'll need to use sequence instead

s/or only of the/or only change within/

marcosc: Mozilla's position on system messages is that they're problematic / bad thing
... something like using Event Pages would be better
... how an Event Page would look like we'll need to discuss
... in this group
... UC: you want to wake up an app do something on the background
... this UC is not addressed by system messages as they bring the full app alive, with a visible UI
... what's in the Runtime spec is lacking, only couple of sentences
... i.e. the Runtime spec as it stands currently is severely underspecified on this

mounir: Firefox OS system messages open UI all the time, but we want to support background page

<room> https://github.com/sysapps/telephony/issues/14

marcosc: we're seeing the limits of system messages
... Mozilla handles this by registering system messages in manifest
... these issues should be throwed at the TAG

<marcosc> https://github.com/w3ctag/api-design-guide

marcosc: it there's confusion around generic design issues such as this, you should file a bug on XXX

Claes: about Promises, I'd like to get guidance on how to use Promises in specs
... "how to write a spec using Promises"
... e.g. then is the resolve algorithm used

<mounir> chaals: not really

<marcosc> https://github.com/slightlyoff/Promises

<room> https://github.com/sysapps/telephony/issues/17

marcosc: original Promises (then Futures) proposal is out of date
... so be careful if you look at the slightlyoff's explainer
... we need to push TAG more so they can refine the Promises spec to be more understandable for wider audience outside implementers
... never throw an exception w/ Promises
... only change we need to make in Raw Sockets API
... filed a but on type checking with Promises
... WebIDL v2 will address issues that break with Promises
... good to keep in mind Promises is no silver bullet

mounir: call for proposals for task forces

anssik: Application Lifecycle and Events was moved to be part of the Runtime discussion on Thu morning

[discussing potential TF topics]

<mounir> Claes: Sockets API discussions

<mounir> mounir: runtime/packaged apps discussions

<zkis> zkis: interested on DataStore used in Contacts, Messaging and Telephony

<zkis> also on Runtime

mounir: proposal, discuss runtime today afternoon, tomorrow split into groups based on interest

<kenneth_> +1

<genelian> +1

<wonsuk1> +1

<JonathanJ1> +1

<spoussa> +1

<zkis> +1

<jmajnert> +1

http://anssiko.github.io/runtime/app-lifecycle.html

<mounir> mounir: what do people what to discuss about runtime?

<mounir> anssik: I would like to discuss this proposal that we wrote

<mounir> ... it seems that the system messages is not that great

<mounir> ... so we should find a way to fix that.

<mounir> ... We call that in our proposal "persistent events".

<mounir> ... This is describing an event page model.

<mounir> ... It is a model with multiple windows and takes care of race conditions when you have multiple windows.

<mounir> ... We wrote down this proposal to cover use cases that are not covered by the current proposal.

<mounir> ... This is currently focused on the packade apps use case but we should keep in mind of the browser use case.

<mounir> ... So mounir, you mentioned issues about design issues in having event pages in the browser, could you share that we us?

<thinker> https://developer.mozilla.org/en-US/docs/WebAPI/Simple_Push ?

<marcosc> anssik: I would like to provide some background on the use cases

<marcosc> ... for the group

Application Lifecycle and Events

<marcosc> anssik: subset of these use cases should be familiar to the group as they were part of the original charter discussions. Adam Barth wrote a draft straw man for outlining some use cases - which we used as input for our use cases.

<marcosc> ... the first use case we name it "A single entry point to the application" - so when you launch an app, there are cases where there should be no UI. For example, as system application that actually that wants to adapt the launch based on the environment conditions.

<marcosc> ... so, like an email application that boots up, sends and email and shuts down without UI.

<marcosc> ... you should be able to create a single entry point for the application - run some application option and then decide if you want to open up an window or not.

<marcosc> kenneth: when you code stuff in C++, you have a main function where you control the main function of the application. so it's a single entry to the application, you can receive information about the environment so you can make decisions about what the application should do - or see why the application was launched, etc.. So we believe that is a model that works very well (given the long legacy from other languages using a "main" entry point).

<marcosc> anssik: as mounir already pointed out, this need to rationalised to web developers as this is a bit of a foreign concept.

<marcosc> anssik: so in the model, a decision can be made as to wether the UI should be shown to the user.

<marcosc> ... in the second use case "behave adapt on launch" is basically what we already covered. It should be up to the developer is the application should be shown on launch. So again, it should be up to the application as to wether a UI should be shown or not.

<marcosc> dsr: so should it be a script that decides this?

<marcosc> anssik: so yeah, we are looking into that - it if should be a document or a script.

<marcosc> kenneth: so it could be a full document, but potentially with some limitations. This document would be able to detect particular lifecycle events.

<marcosc> anssik: so it's kinda like you create a worker - or that is at least one way to design this... or one could use a document, which would be easier for developers to work with.

<marcosc> marcosc: debugging workers is hell

<marcosc> anssik: yes, it's complicated and the tools are not there.

<marcosc> anssik: so using a HTML page (together with all the platform APIs) you can basically create a UI but it's just not visible.

<marcosc> kenneth_: in Chrome, it's a browser instance but not showing any UI.

<marcosc> mounir: so why not use a worker?

<marcosc> kenneth_: because you don't get access to the platform APIs.

<marcosc> anssik: if you start with workers, you don't get any platform APIs

<marcosc> mounir: we had this discussion within mozilla, but we felt that workers would be better because we could limit the number of APIs available and they are more memory efficient.

<marcosc> kenneth_: the problem is that you don't have access to APIs like geo

<marcosc> lgombos: I think this one of the key issues - though I don't have a strong stance on this.

<marcosc> lgombos: you can think this in either as a worker or as document - kinda similar to node.js, which provides a powerful set of APIs. I don't know which one is better.

<marcosc> anssik: my take away from this is that we agree on the use case, but not so much the solution.

<marcosc> kenneth_: we need more than just a worker - but we should probably seek more feedback from the web community.

<marcosc> anssik: we need to write code and experiment here

<marcosc> marcosc: in a previous life, a system I worked on used documents and developers found it very useful to be able to load jQuery, use XHR, etc. That would not be possible right now with a worker

<marcosc> mounir: this is a very basic thing people try to do... example, with google docs: you want to create an instance that shares the logic across pages (aka, shared workers).

<marcosc> mounir: there is no technical reason why we can't add XHR to workers

<marcosc> anssik: one use case that would require a document would be to create document fragments in one page and pass them to another.

<jungkees> Within worker context, we cannot fully make use of xhr request, e.g. cannot set response type to document, etc.

<jungkees> So, in terms of that example, worker context has limitations.

<marcosc> dsuwirya: I think this is an interesting feature - but is it the intention to provide some kind of services or "middleware" for applications?

<marcosc> dsuwirya: on Android, we can build such things on Android.

<marcosc> kenneth_: you can probably do that on Google's app platform using inter app communication - but not so much with this proposal.

<marcosc> anssik: so the use case for having a document is to construct the UI in the "main" document and then send in the UI into that.

<marcosc> thinker: I don't see the reason as to why we would have a single entry point?

<marcosc> thinker: we don't need every application to have a single entry point.

<marcosc> kenneth_: I would put it the other way. I was to have a way of making it very simple - where you have multiple windows, one shuts down, but you still have a single point to handle events at a single point.

<marcosc> kenneth_: it's very complicated at the moment and it's very hard to get wrong because with shared workers you need to wire that all the dependent pages. With a single entry point, you have a single point from which to work from and control things. This reduces the potential to get things wrong.

<marcosc> thinker: it still has potential issues - like more memory usage, etc.

<marcosc> [discussion about background vs foreground pages... etc]

<marcosc> dsr: I think we can learn from browser extensions - from my experience, it should be possible to say if there a HTML page or a script. The tricky part is communication across documents.

<marcosc> marcosc: in Opera extensions we found the same thing. So we ended up exposing an attribute that was a reference to the window object of the containing documents... that make it easy for developers.

<dsr> Chrome makes it easy to launch background from manifest which is nice, and in principle, the manifest could launch background or foreground. We however need to make it easier to communicate between foreground and background.

<marcosc> marcosc: better than using cross-doc messaging, which is hard.

<marcosc> Dong-Young: in your model, it sounds like javascript first - we already have some technology for doing applications without UIs. It all comes down to is if there is compelling use case for this - in your document, you need to clarify the use cases a bit more.

<marcosc> anssik: would you be willing to do some experimentation in Node.js to achieve the same thing? I would like to see running code in node.js to prove your point.

<marcosc> anssik: we can talk offline about it a bit more

<marcosc> anssik: The next one is "Termination sequence"

<marcosc> anssik: our thinking is that before the app gets terminated, it should be able to do some cleanup . The important point is that the system can kill an app at any point, but it will never close it before calling this event.

<marcosc> anssik: the final one is creating windows

<marcosc> anssik: we current have window.open, but it's not quite what we need... it has a lot of legacy baggage.

<marcosc> kenneth_: we are still working on the use cases for this

<marcosc> anssik: if you have worked with window.open, it's synchronous, etc.

<marcosc> mounir: it's not really synchronous

<marcosc> anssik: we should look at the requirements

<marcosc> anssik: I won't read them out loud, but I encourage everyone to take a look at them

<marcosc> anssik: please digest this idea over lunch and we will look the API proposal after lunch.

<mounir> [lunch break]

<timeless> scribe: Josh_Soref

<timeless> scribenick: timeless

Environment

mounir: ehsan is trying to fix the A/C
... (by finding someone to fix it)

Application Lifecycle and Events

anssik: should we go over the requirements?

<room> http://anssiko.github.io/runtime/app-lifecycle.html#requirements

[ anssik enumerates UCs/Requirements ]

1. An application (e.g. a background service) must be able to run without visible user interface.

anssik: the first requirement is from the perspective of packaged applications
... we should try to make this work for regular web content

kjwallis_: when you say application/background service
... what UCs were you considering here?
... I see ... "a persistent service", like location tracking
... or "an event based service"
... I think both UCs are valid but they might have different Requirements
... what informed these requirements

kenneth_: when i plug in my SD card, i want to be launched
... and start a photo importer
... it could also be a polling app

kjwallis_: i just wonder if different platforms might impose different restrictions based on what they want to do
... BB10 imposes different restrictions on what could be done in the background

kenneth_: if you're allowed to do this, you might have to install it

kjwallis_: an would be registered for this
... does the app have to be run first?
... would there be a way to do this from the manifest

kenneth_: in chrome there's an OnInstalled event
... maybe run w/ limitations

anssik: other questions?

2. An application must be able to decide when to show the user interface, if at all. It should be up to the application developer to decide when it is appropriate to show the user interface.

mounir: the runtime should be able to close the application even if the UI is visible

anssik: that isn't preferred

mounir: we shouldn't define things this way
... just say "the runtime should be able to close an application at any time"

3. An application must be able to show the user interface only after it is fully constructed and all the needed data has been loaded.

marcosc: we faced the same problem in Responsive images
... you don't actually know
... you need an explicit way to know when your UI is completely layed out
... when this discussion happened on whatwg for ready

anssik: our model... the developer is in control
... you invoke window.show() when your business logic is ready

kenneth_: i want to create a window, check screen size
... when it's "ready", i show it

mounir: i tried some experiments using chrome apps
... i saw what you demod
... having to open a window when you launch an app
... it's silly
... everyone wants a window

anssik: i had this discussion with kenneth_
... i agree w/ mounir
... but we have to make sacrifices
... we have to serve all UCs

mounir: we can have a way to say in the manifest
... "i want this page"
... or "i want this script to run w/o a page"
... if you have to write 10 lines of JS
... this is a waste of time...

kenneth_: it's a difficult situation
... we wanted it to be hard for people to create applications
... with bad UX
... this is the position apple takes w/ iOS

mounir: i don't see how your proposal improves UX
... you're making life harder for everyone
... and expecting people to do the right thing

<opoto> +1 w/ mounir

mounir: everyone knows that if you expect people to do the right thing on the web
... it won't work

kenneth_: i need to create a window
... if i didn't create specify hidden
... it will show up
... this gives you the ability to show a splash screen
... you can do it, it's possible

mounir: i understand
... your point of view
... but you're being very sophisticated
... as a developer, i was very surprised that i had to create that file
... just to get a window to show up
... if you want something very complex w/ system messages, you can do that

kenneth_: Chrome allows you to use JS files and XML files
... it could be possible for you to give it an html file and have it just show it in a window

dsr: very simple
... from the developer's PoV
... window:html or background:somescripts
... there are lots of complication in Chrome extensions
... an implicit html
... i think it should be really simple
... window:htmlfile
... or backgroud:script
... keep it simple

marcosc: the UC they have is that you do it imperatively
... you're right it should be possible to do it declaratively

dsr: in Mozilla's push proposal
... you register different html files for different contexts

marcosc: there are different ways to skin this cat
... but this can definitely be put into the manifest
... we have starturl

anssik: launchpath

marcosc: it could be an object
... it could have a property `hidden`

timeless: you can already handle a splash screen today, you do not require some complicated thing to know when you are ready
... you can use CSS to make an image fit the entire screen
... this is not required
... for everything else, you might want to use the manifest with different entry points, like startup or events

<marcosc> http://marcoscaceres.github.io/playground/splashscreens/

mounir: i was going to say the same thing
... we had a long fight internally about a splash screen
... in the manifest

marcosc: this holds until it loads content and then goes

kenneth_: 2s 5s... it could be 200ms

marcosc: we need to gather numbers
... for mozilla, the UX guys said "we need splash screens"
... we asked how long does it take to load your content
... and it was 100ms
... 100ms on this device, it isn't noticable
... you click, it does an animation, and loads it
... on Cordova, the startup dance takes i don't know how long

mounir: if the runtime knows it will take a long time to open the app
... we had the same issue w/ Firefox for Android
... have a runtime that can open apps
... it's quite slower on Firefox OS
... we could simply have a generic splash screen made by the runtime
... it could say "this is starting"
... most people see this every day on OSX
... the app just bounces
... and when the app is ready, OS X shows the window
... we could do that same behavior

kenneth_: i agree that i don't want us to specify a splash screen api
... OS X doesn't create a white window and wait five seconds
... i want to make sure it's possible to make it seem like it has

mounir: you'll end up w/ the opposite result
... what takes time is creating process, loading resources
... you're on Firefox OS
... you deal w/ zip file
... create process
... this takes time, this is the longest part
... when you can run that script, you're mostly done
... the time you win by saying "that window is going to load"
... to make it look like it's immediate
... it's the opposite
... say i'm bouncing on OS X
... the app will no longer be bouncing
... but i'll see nothing
... and then i'll see the app ready
... the same thing when Chrome would show an image of the Chrome UI
... and then the Chrome UI would load
... a common behavior nowaday

kenneth_: i think we can remove that UC

kjwallis_: the splash screen UC
... i think the platform will have to handle that
... as mounir was saying
... whether the platform owns or wants to pass it on to the developer
... i had more to say, but you covered it already
... if the platform wants to pass it on to the developer
... there would be some way to define extensions to the manifest
... i don't think the manifest needs to cover it
... but the platform might want to extend it

marcosc: "yes"

[ laughter ]

marcosc: we went around 2 months
... mounir, myself, chaals1
... that's one of the drawbacks of JSON
... you can shove things anywhere
... w/o a way to control extensibility
... we don't have a good way
... we have proposals, they're fairly ugly
... we know cordova made a bunch of extensions
... blackberry made a bunch of extensions
... we considered banning getting to the manifest file altogether
... we could add a data member, not for vendor extensions, but for app specific data
... it isn't easy

mounir: there was a time when people used prefixes
... but prefixes are bad
... we might lose interop
... we might end up w/ sniffing if people can read the manifest
... how to allow w/o messing w/ interop

lgombos_: not sure if splashscreen is gone
... if there are performance requirements
... we should capture that
... splashscreen is an example, if we have a requirement
... we should define what the constraint is -- maybe only static images
... but it's a general comment

mounir: you can only say it's a performance issue
... if you have implementation experience
... you shouldn't call something a performance issue w/o data

4. The runtime model must support authoring an application (or a service without user interface) that can be terminated without user’s consent, and that is able to restore to its previous state.

anssik: example is an application that opens multiple windows
... it's terminated
... it should be able to resume it's previous state

kenneth_: it should be possible for the application
... if it wanted to, to restore its previous state

mounir: how is that not doable nowadays?
... on the web
... every application can be closed at any time
... you can start them again
... how much is this something we need to support
... and something they know how to do

marcosc: we know the strategies used to do this
... people use URLs to reconstruct the application
... serializing state and building back up

mounir: more general comment about terminate event
... i understand the idea
... and where it's coming from
... we don't have it on the web
... it doesn't break
... they might get onclose
... is there a real UC

anssik: distinction between a web page closing
... and the user closing
... for apps the system can terminate w/o user consent
... there's an expectation that it can close

marcosc: because there's no url to go back to
... on android
... they serialize the application

kenneth_: chrome apps
... it calls terminate and runs for at most 1s

mounir: wonder how much it isn't a design flaw to say there's a terminate event
... Firefox for Android was so slow to save its state
... that it was killed by the system
... that when you opened it again
... it wasn't in the same state
... a simple solution is to save your state as you go
... if at any time you're closed
... you can resume
... then having a terminate event will push applications to be lazy
... saving only when they're killed

Josh_Soref: +1

dsr: so this is about developer guidelines

kenneth_: we added a note in the spec that you should save your state once in a while
... with a system app, you might be connecting to hardware
... it might be useful to do bluetooth

mounir: not sure how the system can not help
... if it knows you're using bluetooth, it can clean up

kenneth_: maybe you can control order of closing

mounir: i'm not against
... i'm saying the arguments aren't strong enough
... if when we work on bluetooth
... someone says "there's no way to handle bluetooth"
... for now, the UC for saving state is wrong
... we're pushing people to do the wrong thing

kenneth_: we can probably come up w/ better UCs

mounir: we shouldn't try to come up w/ better UCs
... we should remove it
... and only add it when someone gives us a UC

kenneth_: i agree
... and i don't mind removing it

<mounir> timeless: first of all, I agree with mounir, I use mobile devices, I tend to drop them and the battery pops out

<mounir> ... and when I put the battery back, the apps I was running don't start again

<mounir> ... the reason is that they don't get a terminate event

<mounir> ... same way, I sometimes force the system to reboot

<sicking> Zakim: Mozilla.a is me

<mounir> anssik: the requirement is more abstract that that

Josh_Soref: bluetooth devices have a timeout, I walk away from them and they survive
... the right design is to ask ppl to save state as they go
... It could be a non-normative thing.

5. After being launched, an application must be able to execute scripts to recreate its state before recreating the actual user interface.

anssik: probably some repetition w/ #3

6. An application must be able to show a different user interface given how the app was launched.

o For example, if launched as a photo picker should not show the default application window, but instead create a special purpose user interface.

mounir: this is clearly a UC we have for Web Activities
... we let you associate an html page w/ a system message
... if the email app is opened by the email activity
... we show the compose page
... the system message has the object with the activity name

7. The runtime must provide a mechanism to prevent an application from being launched unneededly.

Google says unneededly has About 21,200 results (0.19 seconds)

kenneth_: UC is System Events
... get USB connected
... instead of forcing filtering on app itself
... you have the ability to create a filtering mechanism that the runtime does

mounir: how is this different from point 1

kenneth_: i get a usb connected to n
... and only in host mode

mounir: how is this related to
... this spec shouldn't define stuff for USB API
... it's a requirement for other APIs to not file events needlessly
... we have a lot of events that are sent too often
... we're asked to send events less often to avoid waking up the device

8. The runtime must provide a one entry point for window creation to prevent race conditions (see #100).

anssik: we should address this

9. The application must be able to create a window and have it laid out correctly with the right dimensions before being shown.

marcosc: you can create a virtual viewport
... and try laying things out
... even when you throw it up on the screen, it might change conditions

anssik: you're talking about adaptive design?

marcosc: windows + laid out correctly

kenneth_: you can use Media Queries on IE

marcosc: this comes back to knowing when the layout is "Done"
... we don't have that today

kenneth_: in chrome, you know

marcosc: there's a bug filed
... it came out of lazy loading that you do want these events
... they're valid UCs
... not sure they should be covered here
... the TAG has talked about it

mounir: it's a larger web issue
... it's something applications really want, but not this spec

kenneth_: this was a brain dump

mounir: but you listed it as a requirement of the life cycle spec

<Zakim> Josh_Soref, you wanted to ask about my screen resolution changing when i "attach" a projector

Josh_Soref: so, I start an application and then I manage to change my screen (like external display)
... so the screen resolution changes
... then you can't assume the screen resolution will never change, it is naive

marcosc: you are right in the larger picture

[showing the splash screen example]

[showing that if you scroll down, the content is being shown after the splash screen]

marcosc: the content starts fading out and I start laying out the rest, if I knew about the details, I could be more intelligent with what I do
... you can work around it but you should not have to be so hacky about it

10. As the persistent events can result in launching dormant apps, it is important that that only happens for subscribed events and it should support some kind of prefiltering, such that if the app listens to say a usb-plugged signal, it can define to only listen to a specific device connected or a specific port.

kenneth_: we'd like prefiltering for events

spoussa: this is the duplicate of the previous one

marcosc: sounds like the drop box UC
... when i plug in a paired phone, it syncs when i plug in
... but for another phone it asks

mounir: no
... it's for saying "when i attach a phone tell me"
... but that's specific to the spec
... not here

Josh_Soref: you're talking about best practices for writing other specs

anssik: this was a subrequirement for 7

marcosc: it should really go to the usb api

mounir: or other apis
... it's good to keep it in mind
... apis send events
... but if events wake an app
... you might do only when needed
... never assume implementers did something for a good reason

kenneth_: sure, we can ask them
... i assume they did it because it was easier

anssik: if we start w/ a main worker
... the appstart-worker
... which apis should be exposed to this context
... if we start w/ document
... then we think about what's not working

<Zakim> Josh_Soref, you wanted to ask if 5.1 can solve the exit() problem by only allowing exit from it

marcosc: maybe

<room> http://anssiko.github.io/runtime/app-lifecycle.html#infrastructure

anssik: this section is even rougher than the UCs
... a Work In Progress
... Application Events -- Life Cycle events
... a reason is passed to the launch event

<scribe> ... pending-evnet,scheduled, other

UNKNOWN_SPEAKER: to be fleshed out

anssik: "other" is used for the user trying to open the app normally

gmandyam: when you talk about persistent events
... for catastrophic/high priority
... how do you make sure the handler is invoked
... you have battery-low-event
... how do you ensure things are triggered immediately and not in a queue?

kenneth_: the way it works in Chrome
... the first thing you do at launch is resubscribe to events
... and when that goes out of scope, you get the actual events

gmandyam: maybe battery isn't a good example
... say you have a 1xEVDO thing up
... you get an incoming-voice-page
... the data connection should be interrupted
... i don't think most EVDO operators are deploying devices
... the application should be able to work off saved data

kenneth_: if an application is running
... the application is invoked immediately
... if it wasn't running
... it's launched, the app registers its handlers, and then gets the event
... the event lets the application shortcut building the UI

<sicking> sorry guys, gotta head out to lunch

gmandyam: i'm asking if the event is so high priority, can it jump the queue

kenneth_: we haven't worried about that

anssik: persistent events aren't like dom events
... they live past the document lifespan
... we have a bunch of notes
... requiring apps to resubscribe at launch
... there are alternatives

<Zakim> mounir, you wanted to ask when the launch event is sent exactly (examples)

mounir: when do you expect to receive the launch event

anssik: the launch sequence
... every time it's being launched (after termination) or for the first time
... My app was running, it was killed, and it's launched from the task scheduler
... is it given the launch event?
... yes

mounir: how does the app know if the user opened it
... if launch only means that the user launched it

[ scribe can't follow ]

kenneth_: since you're killed
... you have to resubscribe to your events at launch
... if you don't subscribe to events, they won't be fired/your handlers won't be called

lgombos_: one of the requirements/UCs discussed
... was deep linking into an application
... like adding-a-calendar-event

anssik: you're asking about the UC of a picker

kenneth_: we haven't looked into Web Activity integration

lgombos_: deep linking UCs might be based on sending the reason in the URL
... maybe you just do #picker at the end of the url
... but maybe that could be how you handle launch reason

kenneth_: we should consider that

lgombos_: thanks

anssik: Filtered Events

mounir: is this coming from Chrome too?

anssik: yes

kenneth_: in chrome it's addListener... here it's addPersistentEventListener
... here you can even have a function
... it would be good to avoid waking up applications

anssik: this api is very un-web-like
... it should be navigator, not navigation
... the listeners only exist in the context of the main document
... onlaunch, onterminate, onterminatecanceled

[ avoid using canceled -- someone will misspell it ]

Terminating the Application

anssik: spin the event loop for UA defined amount of time
... mounir said this encourages app developers to do cleanup at terminate
... instead of persist as you go

Josh_Soref: +1 to mounir

TerminateCanceledEventInit

anssik: if it starts cleanup, and then gets another event to start
... i hope the UC could be reused

<Zakim> dsr, you wanted to comment on LaunchEvent

dsr: quick question
... can i find out which persistent event?

kenneth_: it's a note we have in the document

wonsuk1: what's the next step for this proposal?

anssik: first, we need an editor
... maybe marcosc ?

marcosc: we'd need a reference implementation

kenneth_: we have some of this

mounir: are you implementing, or using what chrome has

kenneth_: we're implementing, probably taking parts from chrome

mounir: i think we need a spec like this
... i'm also worried that Web Apps might do Event Pages
... we should try to sync with them

spoussa: did they start?

mounir: no, but they might start
... even if we start, the people behind Event Pages in WebApps would move forward
... we'd lose
... I think we should change the scope to Event Pages
... i think most of the spec works fine for the web
... so focus on that

[ Break ]

Dinner Plans

mounir: 7pm, Le Sélect Bistro

<kjwallis_> Wellington street

<wonsuk1> Le Sélect Bistro

Runtime Spec

<mounir> Runtime and Security Model for Web Applications

mounir: the reason there's no one working on that spec
... is that it's a waste of time
... it was a brain dump
... we didn't get some implementation feedback
... from a member who tried to do things in a different way
... we got nit-pick feedback about "oh, it doesn't work if you have multiple windows"
... we were expecting/what we want...
... was people w/ real experience w/ implementation/usage to say
... this is working, this isn't working
... i'm glad to see that Intel is interested in implementing something completely different
... so we could share experience
... i think the Runtime Spec should be split
... the DOMRequest is no longer needed
... we're using Promises
... the Manifest file moved to WebApps (marcosc took ownership)
... a bit will need to be defined for apps
... App Management is something that's mostly Mozilla's vision
... i'm not sure many people share it
... System Messages we want to kill
... in favor of Event Pages
... many things can be (re)moved
... to a different spec
... and many things don't seem to have interest from other parties
... we should focus on things that people have interest in
... System Message as Event Pages
... Application Lifecycle (also Event Pages)
... and Package App
... Manifest (in Web Apps)
... if we work on that, maybe we can decide what a short term goal
... if you have an app, it could run on every runtime that implements this
... there's no chance of someone implementing all of this
... so i think we should divide it into digestible bits

gmandyam: beyond how mozilla implements this
... most os's view application manager as something that other third party apps can invoke
... how important is it for an application to get information about other app metadata?
... you can get that from a web interface
... you probably don't want to expose delete/install to third party apps
... you probably want a preinstalled app manager

mounir: we wanted to make this a truly open platform
... the api is open
... so amazon could have an app store
... facebook could have an app store
... but they could only manage apps from them
... there's a way to access every app from the system
... this is...

<anssik> I carved out these management APIs into their own spec a while ago: http://anssiko.github.io/runtime/privileged.html

mounir: there's a bit of management that's privileged
... for a home screen to be able to list every app

gmandyam: you wouldn't want everyone to have that

mounir: yeah, that's behind a pref

gmandyam: with existing web services today, you've offered quite a bit to developers today
... to put up app stores
... they can use url triggered download-install
... install origin/manifest access

mounir: oh, you're talking about the `interface Application`
... if you're an app store, you want to show an app has updates available

gmandyam: you could possibly do that through a preinstalled app manager
... if you have an app store, you can expose that through your own content managing system
... User buys device
... installs Amazon app store
... how is the api aware of this
... whoever is deploying an app store can expose a web service to provide that information
... it can use its own api to access that information

mounir: you should open an issue
... it might be easier to explain in writing

gmandyam: app: is separated, manifest.json is split out
... i think this can be relegated to a NOTE

mounir: this document is a FPWD
... i don't think it's going to LC
... i think it's interesting to show it as an FPWD
... to show that the group plans to specify those features
... moving to a NOTE gives the wrong signal

gmandyam: it tells you that implementers have some latitude on security/etc.

mounir: all of that needs to be standardized

gmandyam: there's a lot of holes
... it's clear it's going to be fine to designate as a NOTE
... and not take this to LC

mounir: i agree we won't take this to LC
... but having a FPWD, we committed to working on this subject
... if we take it to a note, it means we don't care anymore

gmandyam: i think we're getting into areas where implementers need to have latitude to make choices
... i don't see the point to work on a spec that won't be going to LC
... we can allow differing opinions

mounir: we need to reach a common opinion

gmandyam: at the end of this, we should retire the brand names, Tizen, FirefoxOS,...

anssik: i split out the application management apis into their own spec

<anssik> Split out ApplicationManagement and related sections

anssik: months ago

<anssik> http://anssiko.github.io/runtime/privileged.html

anssik: to make the runtime more digestible
... gmandyam, you were concerned about the management apis specifically
... i question the value of standardizing some apis
... if we want to standardize, i think we should be clear on the application boundary
... i think they should be defined where the security boundary

gmandyam: +1

anssik: mounir, what do you think about this?

mounir: this is a good example of what i mean by people tend to nitpick the spec
... app management isn't the main thing in the spec
... i don't think it's worth spending our time discussing is this useful
... mozilla has a good reason for having this there
... we want multiple marketplaces
... but people mostly don't like that idea
... if we remove that
... it doesn't change the general gist of the spec

anssik: i think we're indifferent on what happens to those part
... drop or carve out

mounir: i still believe it's important to have it
... if someone has a solution for multiple marketplaces w/o exposing those apis

anssik: is it easier to organize them into another spec because of the security spec

mounir: you only access apps you installed
... the marketplace application only has access to apps it itself has installed
... which reduces the security issues

<Zakim> Josh_Soref, you wanted to talk about process

Josh_Soref: in DAP, we tried to "SHELVE" things
... to indicate "we aren't working on this"
... but people not following W3 process will find anything that isn't published as a NOTE and say "ooh, it's a REC track document, so i implemented it"

<anssik> an example of a shelved spec: https://dvcs.w3.org/hg/dap/raw-file/default/contacts/Overview.html

Josh_Soref: a big banner at the top of a document doesn't work
... you actually have to publish to /TR/-NOTE- space

<gmandyam> Another example of a spec that has been transitioned to a note: http://www.w3.org/TR/2012/NOTE-streamproc-20120531/

marcosc: we can put OBSOLETE in the background

Josh_Soref: it doesn't work

dsr: if we move it to a NOTE
... we need to publish the new specs (FPWD)

mounir: there are many things to fix
... we don't have a replacement yet
... saying we're going to remove that document
... it's just moving the problem
... if we say we have new documents and they have the same immature documents
... it doesn't fix anything
... the document is immature because no one is interested and it's too big
... we have people interested in implementing, but no one willing to give feedback
... the spec will become like DAP specs
... Vibration and Battery
... mozilla pushed for something in Battery, people had comments
... we fixed them, but no one challenged our vision
... and that's unfortunate
... that's what we're looking for

anssik: the issue is that people outside this room are unclear of the status
... not letting them know the status isn't helping
... we're not aware of implementations
... and it hasn't been reviewed by implementers
... we're looking for implementers
... i'm looking for things
... people who know will find ED
... but people who use google will find TR

dsr: if we're looking for implementation experience, then we should update the TR

mounir: i'm open to updating TR status saying it's a draft, and it's not ready to be implemented
... but FPWD means that
... anyone else w/ comments on the runtime spec?

[ Silence ]

opoto: generic question
... on specific details, but general approach
... about installed applications
... we raised it on github
... #108

<room> Executing installed System Applications in browser

opoto: the specification isn't clear
... and i think we should all have the same understanding
... there was a response from jmajnert
... want to know about the room's opinion
... is it in the same runtime?
... my understanding is that it should be able to run it in the same browser session
... a web page could redirect to an installed app
... or an installed app could redirect to the originating application
... or allow an installed app running w/in an iframe

Josh_Soref: speaking from the Web Intents TF
... we pushed out on iframe to later because it was scary
... it's incredibly valuable to be able to attack privileged apps

mounir: each App has its own Cookie Jar
... the Browser and the NYT app have different Jars
... after this, i'm looking for people to come w/ experience
... i think a nice web model would be, if you install the NYT app, and you go to NYT, they'd share state

[ Josh_Soref delivers a news flash about NYTimes.com and Twitter having their DNS hacked ]

[ which results in scary propositions in case you had an installed app which was interested in trusting the user ]

marcosc: it annoyed users in Opera to install an app having already been logged in
... having to log in again

<Zakim> Josh_Soref, you wanted to talk about NYT+Twitter+@SEA

mounir: i can add a note saying that this is looking for feedback
... we can work on event pages and packaged apps
... hopefully we can move forward on them
... App Manifest v. Packaged App Manifest

marcosc: origin: field
... permissioning
... stuff
... ok, a larger packaged apps spec might be ok
... um. ok.

Agenda

mounir: tomorrow morning is device capabilities
... nothing else
... we can discuss device capabilities, but it'll be quick
... but the rest is ....
... do we want to move the TF to tomorrow morning?

anssik: we could work on life cycle and nail down issues

mounir: we could try to work on event pages
... try to work on datastore
... try to work on socket api
... are people interested, except the four of us?

Claes: is anyone more than me interested in talking socket api?

marcosc: i'm interested

mounir: we can't talk about all things at the same time
... but, marcosc, you can't be in multiple places at once, right?
... who here for Socket API?
... 4
... Datastore
... 4
... Event Pages
... [most of the room]
... we could have a group for datastore+telephony

zkis: i think they're quite different

marcosc: what are we doing in the afternoon?

zkis: i think datastore could be an hour
... sockets, an hour
... event pages may take more than an hour

mounir: a long time

zkis: telephony

mounir: maybe two sessions

marcosc: maybe three
... you can do it

mounir: we could start with Socket / Event Pages
... Datastore / Event Pages

zkis: but, mounir, you need to be in both

mounir: i can't split in two

spoussa: i support your proposal

zkis: socket/telephony is different people

<anssik> +1 on the suggested TF split

zkis: sequentially Datastore+

mounir: i'm open to a Telephony session

marcosc: how much time do we need in the afternoon

mounir: i'd like to keep time there

marcosc: dev outreach

[ hand waving ]

[ laughter ]

mounir: i was expecting feedback on the agenda in advance

marcosc: I made something

[ Applause ]

marcosc: for things you want to attend, put your names on stickies
... when you've done that, you're free to go

[ Adjourned ]

- DRAFT -

SysApps Face-to-Face #2

28 Aug 2013

Attendees

Contents

Agenda

Telephony

API Design

Application Lifecycle and Events

Environment

Application Lifecycle and Events

Dinner Plans

Runtime Spec

Agenda

Summary of Action Items

Scribe.perl diagnostic output