13:13:21 <RRSAgent> RRSAgent has joined #sysapps
13:13:21 <RRSAgent> logging to http://www.w3.org/2013/08/28-sysapps-irc
13:13:23 <Zakim> Zakim has joined #sysapps
13:13:32 <timeless> Scribe: Josh_Soref
13:13:35 <timeless> ScribeNick: timeless
13:13:46 <timeless> Zakim, this is SysApps
13:13:46 <Zakim> timeless, I see UW_SYSAPPS()8:00AM in the schedule but not yet started.  Perhaps you mean "this will be SysApps".
13:14:00 <timeless> Zakim, this will be SysApps
13:14:01 <Zakim> ok, timeless; I see UW_SYSAPPS()8:00AM scheduled to start 74 minutes ago
13:14:43 <timeless> RRSAgent, draft minutes
13:14:43 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/28-sysapps-minutes.html timeless
13:14:49 <timeless> RRSAgent, make logs world
13:14:50 <timeless> RRSAgent, draft minutes
13:14:50 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/28-sysapps-minutes.html timeless
13:15:07 <timeless> Chair: mounir, wonsuk
13:15:17 <timeless> Agenda: http://www.w3.org/wiki/System_Applications:_2nd_F2F_Meeting_Agenda
13:15:25 <timeless> RRSAgent, draft minutes
13:15:25 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/28-sysapps-minutes.html timeless
13:15:43 <timeless> Meeting: SysApps Face-to-Face #2
13:15:46 <timeless> RRSAgent, draft minutes
13:15:46 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/28-sysapps-minutes.html timeless
13:16:20 <zkis> zkis has joined #sysapps
13:16:25 <Zakim> UW_SYSAPPS()8:00AM has now started
13:16:32 <Zakim> +[Mozilla]
13:17:40 <lgombos__> lgombos__ has joined #sysapps
13:18:24 <timeless> topic: Telephony
13:18:27 <timeless> wonsuk: good morning
13:18:37 <timeless> ... first we'll talk about Telephony, zkis will lead the discussion
13:18:43 <lgombos> lgombos has joined #sysapps
13:18:45 <timeless> s/topic: Telephony/topic: Agenda/
13:18:56 <timeless> ... after that, we'll talk about generic API Design issues
13:18:57 <Dong-Young> Dong-Young has joined #sysapps
13:19:13 <anssik> Present+ Anssi_Kostiainen
13:19:13 <timeless> ... and then we'll probably split the group before having lunch
13:19:21 <timeless> ... does anyone have comments on that?
13:19:27 <dsuwirya> dsuwirya has joined #sysapps
13:19:33 <timeless> zkis: could we ask which people are interested in that?
13:19:34 <jungkees> Present+ Jungkee_Song
13:19:39 <timeless> mounir: we should discuss groups before lunch
13:19:44 <timeless> topic: Telephony
13:19:51 <lgombos> Present+ Laszlo_Gombos
13:20:24 <wonsuk> Present+ Wonsuk_Lee
13:20:44 <genelian> genelian has joined #sysapps
13:20:46 <Marta> Marta has joined #sysapps
13:20:48 <room> room has joined #sysapps
13:20:53 <mounir> Present+ Mounir_Lamouri
13:20:54 <marcosc> marcosc has joined #sysapps
13:21:00 <jmajnert> jmajnert has joined #sysapps
13:21:03 <opoto> Present+ Olivier_Potonniee
13:21:11 <Claes> Claes has joined #sysapps
13:21:15 <thinker> Prsent+ KueiFong_Lee
13:21:18 <timeless> zkis: we won't discuss using System Messages / Factory objects
13:21:31 <timeless> ... i'd like to discuss how we deal w/ Telephony Services (CDMA...)
13:21:39 <timeless> ... the rest of the details can be discussed offline
13:21:46 <thinker> Present+ KuiFong_Lee
13:21:57 <wonsuk> http://www.w3.org/2012/sysapps/telephony/
13:21:58 <JonathanJ1> JonathanJ1 has joined #sysapps
13:22:14 <Claes> Present+ Claes_Nilsson
13:22:17 <JonathanJ1> Present+ Jonghong_Jeon
13:22:21 <timeless> s|http://www.w3.org/2012/sysapps/telephony/|-> http://www.w3.org/2012/sysapps/telephony/ Web Telephony API|
13:22:27 <wonsuk> left issues: https://github.com/sysapps/telephony/issues
13:22:48 <timeless> zkis: telephony is based on standards
13:22:48 <wonsuk> q?
13:22:57 <timeless> ... the standards are implemented by modems
13:23:02 <timeless> ... with varying command sets
13:23:11 <timeless> ... and there are also sim cards
13:23:21 <genelian> Present+ Gene_Lian
13:23:23 <kjwallis_> kjwallis_ has joined #sysapps
13:23:28 <JonathanJ1> JonathanJ1 has joined #sysapps
13:23:40 <timeless> ... The Ofono stack has the best handling of modems
13:23:54 <timeless> ... i wanted to show its API set
13:24:13 <hsinyi> Present+ hsinyi
13:24:15 <room> http://git.kernel.org/cgit/network/ofono/ofono.git/tree/doc/modem-api.txt
13:24:57 <timeless> zkis: one of the interface is voice call
13:25:04 <timeless> s/interface/
13:25:17 <timeless> s/the  is/the interfaces is/
13:25:31 <timeless> ... trying to map all of these things into a dialer is quite difficult
13:25:48 <timeless> ... the Web Telephony API is trying to do a simple mapping
13:25:56 <timeless> ... it assumes you have a modem, and the modem is online
13:26:12 <timeless> ... if we don't have a telephony object on navigator, then the modem isn't available
13:26:22 <timeless> ... when we dial out, there's a serviceId to be used
13:26:32 <timeless> ... it's roughly a subscriber ID + service itself
13:26:39 <timeless> ... a SIM card is a Subscriber identity module
13:26:51 <timeless> ... in combination with a service, like Telefonica
13:26:57 <timeless> ... they represent a service
13:27:04 <timeless> ... the serviceID is a unique identifier
13:27:24 <timeless> ... the problem with this approach is that it doesn't provide any means to use other functionality present in Telephony
13:27:31 <timeless> ... when we do Network API or SIM API
13:27:41 <timeless> ... it would have to be done on a different Navigator object
13:27:59 <timeless> ... maybe instead of presenting [string] IDs, we could present Telephony Service objects
13:29:06 <room> https://etherpad.mozilla.org/O0KQaiKEhN
13:29:26 <wonsuk> q?
13:29:28 <timeless> s|https://etherpad.mozilla.org/O0KQaiKEhN|-> https://etherpad.mozilla.org/O0KQaiKEhN zkis API proposal|
13:29:43 <timeless> [ zkis projects API proposal ]
13:30:19 <timeless> zkis: service, provider, displayName, method for dialing, sending tones, getting calls
13:30:33 <spoussa> spoussa has joined #sysapps
13:30:33 <timeless> ... you could have a call active, and receive another call
13:30:53 <timeless> ... you might be talking w/ a telephone
13:30:58 <timeless> ... and reject Skype calls
13:31:32 <timeless> gmandyam: on the 1x call in Verizon, the Skype calls are over the service switched path
13:31:54 <timeless> zkis: you could set Skype up a port for IP
13:32:02 <timeless> ... as well as circuit switched
13:32:15 <timeless> ... -- but, this is about a policy
13:32:23 <timeless> gmandyam: you need data concurrency
13:32:28 <timeless> ... but CDMA blocks
13:32:42 <timeless> zkis: since we have the capability to support both types of policies
13:32:46 <timeless> ... this isn't an argument for it
13:32:49 <timeless> ... but this solves it
13:32:53 <spoussa> Present +Sakari_Poussa
13:32:57 <timeless> ... it also solves differences in protocols
13:33:09 <timeless> ... it also presents SIM info, telephony, network
13:33:50 <timeless> zkis: on TelephonyManager, we have a handler for incoming calls
13:33:55 <timeless> ... and also on the service
13:34:29 <timeless> gmandyam: can you go down to conference call handling?
13:34:45 <timeless> zkis: conference call handling is the same, but it's on a different service
13:35:04 <timeless> gmandyam: in the old system you called join() which returned a conference call
13:35:13 <timeless> zkis: yes, it's the same here
13:35:23 <timeless> ... but it's differently for VOIP
13:35:34 <timeless> ... we discussed conference calls in a one-on-one meeting
13:35:38 <timeless> ... i raised issues on it
13:35:46 <timeless> anssik: zkis, which options makes the common UC simple
13:35:55 <timeless> ... while allowing for complex UCs
13:36:09 <timeless> ... if you want to make a web app to implement the common UC
13:36:22 <timeless> zkis: the old approach is simpler to use for people who don't care about telephony services
13:36:28 <timeless> ... and assume there's a service available
13:36:38 <timeless> anssik: you're saying the common use
13:36:56 <timeless> zkis: i'm saying we could have an object representing the service
13:37:10 <timeless> ... but the problem with the old approach is that there could be no service available
13:37:15 <timeless> ... you want to dial
13:37:23 <timeless> ... and there's no indication that there's no service
13:37:37 <timeless> ... it has problems on the error path handling
13:37:53 <timeless> zkis: another option is TelephonyManager is a default telephony service
13:37:58 <timeless> ... but then your object could change
13:38:09 <timeless> anssik: how common is it that it changes?
13:38:17 <timeless> marcosc: someone pops out the sim
13:38:23 <timeless> anssik: could we just have "things are broken"
13:38:34 <timeless> marcosc: zkis was saying that the error handling path
13:38:45 <timeless> ... dialing is a top level thing which assumes a default service available
13:38:48 <timeless> ... which may or may not be true
13:38:59 <timeless> ... not having navigator.telephonyManager being a service is a problem
13:39:09 <timeless> ... there are advantages/disadvantages to either approach
13:39:21 <timeless> ... 90% of the time there's a sim, and it's a phone, so it can dial 911/112
13:39:29 <timeless> ... you could mix/shift things around
13:39:32 <timeless> ... it's not that hard
13:39:42 <timeless> ... but for more advanced UCs, you might want to access SIM
13:39:47 <timeless> ... it gets kind of funky
13:40:01 <zkis> q?
13:40:15 <timeless> ... i don't know what access to the telephony service itself allows
13:40:27 <timeless> zkis: i think it would makes sense to depict the developer flow
13:40:32 <timeless> ... when you write a dialer flow
13:40:39 <timeless> ... you need to handle PIN query
13:40:46 <timeless> ... and you need to handle Emergency calling
13:40:52 <timeless> ... in Dialer, it's in contextual
13:41:12 <timeless> ... it may be a Phone Number, and MMI string, an USSD, or an Emergency Number
13:41:24 <timeless> ... based on what the user is typing, the UI may [need to] change
13:41:36 <timeless> ... these all pretty much complicate the dialer
13:41:43 <timeless> ... we try to make it easy for alternative dialers
13:41:49 <timeless> anssik: you're an expert in Ofono
13:41:56 <timeless> ... do you know how it looks on Android?
13:41:59 <timeless> zkis: yes
13:42:05 <timeless> anssik: what's the API?
13:42:08 <timeless> zkis: it's very low level
13:42:22 <timeless> ... it exposes GSM/CDMA
13:42:30 <timeless> anssik: what type of third party apps are people building?
13:42:38 <timeless> zkis: there's no problem for Android developers to use them
13:42:51 <timeless> ... the assumption is that Operators or people in the Telephony business are writing them
13:42:58 <timeless> ... we don't expect to have 1000 dialer apps on a store
13:43:01 <timeless> anssik: exactly
13:43:10 <timeless> ... so the target audience isn't millions of developers
13:43:14 <timeless> zkis: that's my understanding
13:43:18 <timeless> ... and the experience on Android
13:43:29 <timeless> ... i wouldn't be afraid of exposing low level functionality in a way that makes sense
13:43:43 <timeless> ... that the application needs to check the services available first
13:43:46 <timeless> ... isn't a problem
13:43:59 <timeless> anssik: so the target audience is a very specialized group of people who know this in and out
13:44:07 <timeless> ... going lower level rather than higher level seems reasonable
13:44:22 <timeless> ... OTOH, if the api is for typical developers, then it makes sense to expose something simpler
13:44:38 <timeless> zkis: the idea was that keeping the API simple would allow more people to write dialers
13:44:53 <timeless> ... but if we had service objects, then people could write more complicated apps
13:45:04 <timeless> ... we could have a method to get a serviceObject by ID
13:45:59 <timeless> hsinyi: the ED proposal is simple and easy to use
13:46:05 <timeless> ... but to provide more complicated apps
13:46:19 <timeless> ... Mozilla has XCC API, and Pin Lock APIs
13:46:26 <timeless> zkis: where do you provide those?
13:46:29 <lgombos> lgombos has joined #sysapps
13:46:35 <timeless> hsinyi: separate objects on navigator
13:46:44 <timeless> s/XCC/ICC/
13:47:03 <timeless> ... and operator API
13:47:28 <timeless> ... with this api, it isn't a problem to create complicated apps
13:47:32 <timeless> zkis: it looks like a hack
13:47:44 <timeless> ... starting with how modems are designed and how the radio is designed
13:47:50 <timeless> hsinyi: if you want to look into the modem
13:47:55 <timeless> ... then a separate ICC
13:48:06 <timeless> ... In SMS/MMS, you need this functionality
13:48:12 <timeless> ... having a separate functionality
13:48:17 <timeless> ... reduces redundancy
13:48:23 <timeless> zkis: you only handle part of the problem
13:48:42 <timeless> ... you can't handle SMS via LTE-IP or Circuit-Switched
13:48:50 <timeless> ... a telephony service can handle that
13:49:05 <timeless> ... how do you know if you have telephony functionality at all
13:49:08 <timeless> ... it could be a Tablet
13:49:45 <timeless> zkis: this handles everything
13:49:55 <timeless> ... i think the Mozilla API is built based on different UCs
13:50:00 <timeless> ... I see a lack of design
13:50:06 <timeless> ... you're adding interfaces as you meet problems
13:50:14 <timeless> ... it wasn't designed properly from the start
13:50:28 <timeless> ... this API is integrated and it handles all the UCs in Telephony
13:50:34 <timeless> hsinyi: I agree that decision
13:50:52 <timeless> ... with all the bits in an api, it's for experienced developers
13:51:09 <timeless> ... but with separate things, we can make simple apis which basic developers can use
13:51:16 <timeless> [ chatter between zkis and hsinyi ]
13:51:46 <timeless> zkis: how simple would it be to have a single structure which handles all of these?
13:52:01 <timeless> ... CDMA service, GSMA service, Skype service, SIP service
13:52:23 <timeless> hsinyi: i'd like to have other members comment on this
13:52:47 <timeless> hsinyi: after talking w/ sicking
13:52:49 <timeless> ... and thinking
13:52:54 <timeless> ... maybe we can provide another way
13:53:06 <jungkees> q+
13:53:22 <timeless> zkis: [do?] we want to provide an API that maps along the existing system
13:53:27 <gmandyam> q+
13:53:33 <timeless> ... i wouldn't want to let Telephony correctness out of the picture
13:53:42 <timeless> ... developers understand Telephony
13:53:50 <timeless> ack jungkees
13:54:18 <timeless> jungkees: a question about the Telephony Event interface
13:54:22 <timeless> ... to receive an incoming call
13:54:30 <timeless> ... the event is driven from a dom event
13:54:36 <wonsuk> q?
13:54:37 <timeless> ... so the telephony app needs to be running
13:54:42 <timeless> ... why not use system messages?
13:54:50 <timeless> ... so the telephony app
13:54:55 <timeless> ... gets the call
13:55:02 <timeless> ... is that a possibility?
13:55:08 <timeless> zkis: we have an issue about it
13:55:21 <timeless> ... in all the phones i've dealt w/, the dialer is a prestarted application
13:55:40 <timeless> jungkees: with native, we don't actually have a running call
13:55:44 <timeless> ... we push it up and run it
13:55:52 <timeless> q?
13:56:01 <timeless> zkis: otoh, we have to guarantee that you can answer the call
13:56:17 <timeless> ... we need an upper bound limit on time to start the app and answer the call
13:56:23 <timeless> ... UI coming up, you press a call
13:56:30 <timeless> ... system messages don't solve that problem
13:56:31 <timeless> Josh_Soref: +1
13:56:37 <timeless> ack gmandyam
13:56:51 <timeless> gmandyam: what's been added to enable IP Telephony?
13:57:05 <timeless> ... i think we have too many efforts to enable IP Telephony in the browser
13:57:20 <kenneth_> kenneth_ has joined #sysapps
13:57:32 <timeless> [ gmandyam enumerates places where people are trying to integrate IP Telephony - W3C, 3GPP, IETF ]
13:57:42 <timeless> gmandyam: i'm not convinced we need to bundle that functionality into this api
13:57:56 <timeless> ... what in your proposal is being added to accommodate IP Telephony
13:58:14 <timeless> zkis: this isn't adding specific things to work with IP Telephony
13:58:20 <timeless> ... except an interface for Conference Call
13:58:30 <timeless> ... a service represents a SIP account or SIM-based account
13:58:57 <timeless> ... except SIM based has services
13:59:13 <wonsuk> q?
13:59:50 <timeless> ... for GSM, we may have a cellular service which implements telephony
14:00:00 <timeless> ... which has sim settings, telephony network, call forwarding
14:00:06 <timeless> ... but they might not be there in SIP
14:00:28 <timeless> gmandyam: i can see that this proposal is better than the current draft
14:00:33 <timeless> ... for CDMA/GSM
14:00:38 <timeless> ... but for implementation/testing
14:00:44 <timeless> ... we'd have to verify that this works for SIP stacks
14:00:55 <timeless> ... i think that's unnecessarily burdensome
14:00:58 <timeless> ... VoLTE is SIP
14:01:07 <timeless> ... but you build that into the stack
14:01:21 <timeless> zkis: you could do IMS with WebRTC
14:01:28 <timeless> ... you could expose that service through this API
14:01:41 <timeless> gmandyam: an implementer could do a valid implementation w/o VoLTE SIP based
14:01:50 <timeless> zkis: if an implementer provides extra bits
14:01:54 <timeless> ... then it has to document it
14:02:08 <timeless> ... now we're talking about a voice call interface
14:02:08 <wonsuk> q?
14:02:15 <timeless> gmandyam: with BREW
14:02:34 <timeless> ... We called it ITAPI
14:03:04 <timeless> ... but CDMA's teleconference model made the system complicated
14:03:13 <timeless> ... because it imposes constraints
14:03:44 <timeless> zkis: call state management is different for CDMA
14:03:49 <timeless> ... you can't guarantee call state with CDMA
14:03:53 <timeless> gmandyam: yes, dialing is strange
14:04:11 <timeless> zkis: it's a pity we don't have anyone from AT&T here
14:04:22 <timeless> ... i think we still need to convince Mozilla
14:04:32 <timeless> ... but i'm open to discussing to work on a usable API
14:04:45 <timeless> marcosc: it's kind of hard to make a call-in
14:04:55 <timeless> ... until we looked into it in more detail
14:05:22 <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.
14:05:22 <timeless> ... this [Etherpad] doesn't look really wrong
14:05:28 <timeless> ... it seems to make sense
14:05:42 <timeless> ... i'm fairly convinced that we need a cellular service object from previous discussions
14:05:42 <dsr> q+ to ask about simple use case
14:05:48 <timeless> ... i don't have an issue with adding this thing
14:06:03 <timeless> zkis: we could do an example of how the development flow goes with both apis
14:06:08 <gmandyam> q+
14:06:15 <timeless> ... checking a few things in a dialer app when you start up, isn't a big deal.. 2-5 lines of code
14:06:24 <timeless> ack dsr
14:06:24 <Zakim> dsr, you wanted to ask about simple use case
14:06:39 <timeless> dsr: on my android phone, i have multiple dialers
14:06:54 <timeless> ... passing in a URI: tel: or sip:
14:07:00 <timeless> ... i imagine the user is asked which thing to use
14:07:11 <timeless> ... i might have multiple SIP services, multiple sim cards
14:07:17 <timeless> marcosc: we have an issue for that
14:07:26 <timeless> ... this API intersects
14:08:08 <room> https://github.com/sysapps/telephony/issues/171
14:08:24 <timeless> s|https://github.com/sysapps/telephony/issues/171|-> https://github.com/sysapps/telephony/issues/171 Describe the relationship to tel:|
14:09:00 <timeless> https://f.cloud.github.com/assets/870154/690783/c2049176-db35-11e2-889f-6799df31e59c.png
14:09:43 <timeless> mounir: in Firefox OS, we have Web Activities
14:09:50 <timeless> ... for tel:, sms:,
14:09:54 <timeless> ... we use Web Activities
14:10:07 <timeless> ... which lets the User choose
14:10:23 <timeless> dsr: if i'm on wifi and i want to use a cheaper calling system (Skype)
14:10:29 <timeless> ... how does a user get to make that choice
14:10:47 <timeless> mounir: Skype and built-in-dialer would be registered for the "dial" activity
14:10:59 <timeless> ... you click dial and and get something like that
14:11:23 <timeless> zkis: or someone implements a dialer which lets you ask which service you want to use on dialing out
14:11:40 <timeless> dsr: so we have the opportunity to customize the UI for that
14:12:00 <timeless> [ Maemo and BlackBerry let you pick the outbound service from the dialer UI ]
14:12:15 <timeless> [ zkis reads through an issue list ]
14:12:17 <timeless> q?
14:12:21 <timeless> ack gmandyam
14:12:56 <thinker> thinker has joined #sysapps
14:13:15 <timeless> gmandyam: a lot of these states don't matter
14:13:20 <timeless> ... i can't even fathom UCs for them
14:13:25 <timeless> anssik: these are from GSM
14:13:30 <timeless> zkis: these are from GSM/CDMA
14:13:33 <timeless> ... some aren't mandatory
14:13:39 <timeless> anssik: are there UCs for all of them?
14:13:46 <timeless> zkis: we had a two month discussion on this
14:13:59 <timeless> ... i was of the opinion that w shouldn't map the states
14:14:05 <timeless> ... because it isn't guaranteed to happen
14:14:39 <timeless> ... <ril.h> -- radio interface layer
14:15:00 <timeless> zkis: my opinion is that we only expose state change with parameters defining state
14:15:04 <timeless> ... and a possible state name change
14:15:25 <timeless> zkis: you need a lot of these
14:15:34 <timeless> ... even GSM networks which have these states
14:15:39 <timeless> ... sometimes they're skipped
14:15:53 <timeless> ... but it was hard to convince dialer developers that the network doesn't provide a fixed state machine
14:16:08 <timeless> ... we have a depiction, but it isn't guaranteed
14:16:14 <room> http://www.w3.org/2012/sysapps/telephony/images/inbound_call_state_diagram.gif
14:16:27 <room> http://www.w3.org/2012/sysapps/telephony/images/outbound_call_state_diagram.gif
14:16:55 <timeless> zkis: these are expected order, they happen 90% of the time
14:17:18 <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.
14:17:25 <timeless> marcosc: "all diagrams are non-normative"
14:17:50 <timeless> wonsuk: i think we have a lot of issues
14:18:15 <timeless> ... we'll have a detailed discussion in the afternoon session
14:18:27 <kjwallis> kjwallis has joined #sysapps
14:18:47 <timeless> zkis: there was a discussion about using constructors
14:20:27 <wonsuk> https://github.com/sysapps/telephony/issues/17
14:20:50 <timeless> s|https://github.com/sysapps/telephony/issues/17|-> https://github.com/sysapps/telephony/issues/17 Evaluate spec for use of Promises|
14:21:06 <timeless> zkis: i argue that on success and error we return a telephony call
14:21:13 <timeless> ... it isn't a simple success/failure
14:22:06 <timeless> zkis: you can't have a telephony call w/o a telephony service
14:22:41 <wonsuk> q?
14:22:43 <timeless> marcosc: you're correct that you need it
14:22:49 <timeless> ... but idiomatically, you can abstract it away
14:22:54 <timeless> ... in terms of objects and behaviors
14:23:04 <timeless> ... anyone can pull the service out at any momemnt
14:23:09 <timeless> s/momemnt/moment/
14:23:14 <timeless> ... the service could go away
14:23:21 <timeless> ... you create the object, then start the dialing process
14:23:27 <timeless> ... what you're saying makes sense
14:23:41 <timeless> ... but idiomatically, it feels cleaner to make the object and then start dialing
14:23:49 <Marta> Marta has joined #sysapps
14:23:51 <timeless> ... you're saying you could make objects and never use them
14:24:04 <timeless> ... but it's idiomatically to create an object
14:24:13 <timeless> gmandyam: should the api recognize airplane mode?
14:25:31 <timeless> marcosc: airplane mode would be detected at dial()
14:25:41 <timeless> zkis: promises handle one end result
14:25:45 <timeless> ... if you disconnect
14:25:50 <timeless> ... you expect a disconnect reason
14:26:08 <timeless> gmandyam: say you Land (flight)
14:26:13 <timeless> ... you get authentication
14:26:17 <timeless> ... initially Emergency
14:26:19 <timeless> ... then Roaming
14:26:23 <timeless> ... then Home network
14:26:26 <timeless> ... first call fails
14:26:30 <timeless> ... that promise gets invoked
14:26:41 <timeless> ... you need some indication to the user as to why it failed
14:26:46 <timeless> ... is that a true error condition?
14:26:55 <timeless> zkis: you're dialing, it goes to network
14:27:03 <timeless> ... it establishes a voice channel and goes to voice mail
14:27:10 <timeless> ... you can't handle that with promises
14:27:17 <timeless> ... you have to handle that with state management
14:27:23 <wonsuk> q?
14:28:17 <timeless> [ marcosc points to https://github.com/sysapps/telephony/issues/17#issuecomment-20193354 ]
14:28:30 <timeless> zkis: you don't know if there's a real call, or a junk object
14:28:36 <timeless> ... there's no telephony object in the network
14:28:56 <timeless> gmandyam: during the last F2F
14:29:03 <timeless> ... didn't sicking say some methods were synchronous?
14:29:22 <timeless> marcosc: it turns out these are asynchronous
14:29:32 <timeless> zkis: if you can do a promises proposal, make a branch
14:29:43 <timeless> marcosc: we've wasted a ton of cycles on this
14:29:52 <timeless> ... you've made a bunch of points
14:29:57 <timeless> ... but the idiomatic design
14:30:05 <timeless> ... you have a point about dependency of the service
14:30:12 <timeless> ... you can keep dead objects around
14:30:16 <timeless> ... after you hang up a call
14:30:21 <timeless> ... so you're asking for getCalls()
14:30:24 <timeless> ... you wouldn't
14:30:30 <timeless> ... you'll only return active ones
14:30:45 <timeless> ... there are issues w/ garbage collected objects
14:30:57 <timeless> zkis: one idiom shouldn't be applied everywhere
14:31:05 <timeless> ... you have to prove it works in telephony
14:31:09 <timeless> marcosc: we could try to do that
14:31:17 <timeless> gmandyam: you'd need to talk about the dead object UC
14:31:21 <timeless> ... when you trigger GC
14:31:24 <wonsuk> q?
14:31:35 <timeless> anssik: below marcosc, i commented about testing this on real JS developers
14:31:47 <timeless> ... but this API won't get much exposure amongst the developer community
14:32:05 <timeless> ... marcosc, do you think this consistency with the rest of the platform is important
14:32:14 <timeless> ... i understand the case if the api would be used by all web developers
14:32:31 <timeless> marcosc: not really
14:32:34 <timeless> ... it's not that important
14:32:43 <timeless> ... but it sets a precedent we're trying to move away from
14:32:53 <timeless> ... we can keep it, but try to discourage future apis
14:32:57 <timeless> anssik: that's a good point
14:33:04 <timeless> marcosc: we're seeing the same patterns through most of SysApps
14:33:14 <timeless> gmandyam: and WebRTC
14:33:31 <timeless> marcosc: the TAG had a call and it got very heated
14:33:39 <timeless> zkis: the issue is still alive
14:33:42 <timeless> marcosc: let's close it
14:33:56 <timeless> marcosc: forget promises
14:34:03 <timeless> ... Factor or Constructor
14:34:22 <timeless> zkis: Promises with multiple outcomes
14:34:27 <timeless> marcosc: that's not going to happen
14:35:21 <timeless> ... the weirdness is that you don't ...
14:35:45 <timeless> marcosc: there's magic behind the API
14:36:01 <timeless> zkis: we need to give an example of the development flow
14:36:07 <timeless> marcosc: we have some examples in the spec
14:36:29 <anssik> +1 on writing more examples
14:37:36 <timeless> zkis: i'm ok with leaving this open
14:37:52 <timeless> marcosc: so we won't do Constructor... we'll keep the factory
14:39:33 <timeless> marcosc: I promise to add more examples
14:39:43 <timeless> [ scribe notes that there's only one example and it's virtually useless ]
14:40:01 <timeless> zkis: mozilla seems to prefer the old way
14:40:11 <timeless> ... gmandyam thinks the service would help solve problems
14:40:16 <timeless> ... i still expect input on this
14:40:17 <wonsuk> q?
14:40:27 <timeless> [ Break ]
15:01:11 <marcosc> Scribe: Marcos
15:01:21 <marcosc> Scribnick: marcosc
15:01:46 <marcosc> TOPIC: API Design
15:02:50 <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?
15:03:15 <wonsuk> q?
15:03:37 <marcosc> zkis: I wanted to ask for feedback about how we deal with signalling this. Do we use a sequence and an event?
15:04:13 <marcosc> marcosc: which example in particular are we talking about?
15:04:26 <marcosc> zkis: let's take the telephony API
15:04:48 <marcosc> zkis: we have an array of calls, for example
15:09:43 <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.
15:10:49 <anssik> ScribeNick: anssik
15:11:09 <anssik> [mascosc explains how task queues are spec'd in HTML5]
15:12:02 <anssik> marcosc: signaling happens at the start of the script exec
15:12:02 <anssik> ... in practice, does not have an effect on developers
15:12:23 <anssik> ... ES 7 will define the event loop
15:12:24 <chaals> chaals has joined #sysapps
15:12:47 <anssik> ... now it's in HTML5 spec
15:12:48 <anssik> ... at least, on TODO list for ES 7
15:13:22 <room> https://github.com/sysapps/telephony/issues/81
15:14:26 <wonsuk> Title of this: Dynamically changing arrays could lead to race conditions
15:15:27 <anssik> zkis: race conditions are a generic issue that needs to be resolved, for example see Telephony issue #81
15:15:29 <anssik> 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
15:15:52 <anssik> s/or only of the/or only change within/
15:16:18 <anssik> marcos: Mozilla's position on system messages is that they're problematic / bad thing
15:16:27 <anssik> s/marcos/marcosc/
15:16:37 <anssik> ... something like using Event Pages would be better
15:16:48 <anssik> ... how an Event Page would look like we'll need to discuss
15:17:24 <anssik> ... in this group
15:17:53 <anssik> ... UC: you want to wake up an app do something on the background
15:18:34 <anssik> ... this UC is not addressed by system messages as they bring the full app alive, with a visible UI
15:19:16 <anssik> ... what's in the Runtime spec is lacking, only couple of sentences
15:19:33 <anssik> ... i.e. the Runtime spec as it stands currently is severely underspecified on this
15:19:56 <virginie> virginie has joined #sysapps
15:20:20 <anssik> mounir: Firefox OS system messages open UI all the time, but we want to support background page
15:20:27 <chaals> rrsagent, draft minutes
15:20:27 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/28-sysapps-minutes.html chaals
15:20:52 <room> https://github.com/sysapps/telephony/issues/14
15:21:12 <anssik> marcos: we're seeing the limits of system messages
15:21:35 <anssik> ... Mozilla handles this by registering system messages in manifest
15:22:30 <mounir> q?
15:22:49 <anssik> ... these issues should be throwed at the TAG
15:22:54 <anssik> s/marcos/marcosc/
15:23:03 <Claes> q+
15:23:16 <marcosc> https://github.com/w3ctag/api-design-guide
15:23:16 <anssik> ... it there's confusion around generic design issues such as this, you should file a bug on XXX
15:23:40 <anssik> Claes: about Promises, I'd like to get guidance on how to use Promises in specs
15:23:51 <anssik> ... "how to write a spec using Promises"
15:24:18 <anssik> ... e.g. then is the resolve algorithm used
15:24:36 <mounir> chaals: not really
15:25:55 <mounir> Zakim, who is on the call?
15:25:55 <Zakim> On the phone I see [Mozilla]
15:26:10 <marcosc> https://github.com/slightlyoff/Promises
15:26:16 <room> https://github.com/sysapps/telephony/issues/17
15:26:34 <anssik> marcosc: original Promises (then Futures) proposal is out of date
15:27:02 <anssik> ... so be careful if you look at the slightlyoff's explainer
15:27:58 <anssik> ... we need to push TAG more so they can refine the Promises spec to be more understandable for wider audience outside implementers
15:28:33 <wonsuk1> wonsuk1 has joined #sysapps
15:28:38 <anssik> ... never throw an exception w/ Promises
15:28:57 <anssik> ... only change we need to make in Raw Sockets API
15:29:17 <anssik> ... filed a but on type checking with Promises
15:29:57 <anssik> ... WebIDL v2 will address issues that break with Promises
15:30:31 <anssik> ... good to keep in mind Promises is no silver bullet
15:31:33 <JonathanJ1> RRSAgent, draft minutes
15:31:33 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/28-sysapps-minutes.html JonathanJ1
15:31:50 <anssik> mounir: call for proposals for task forces
15:32:18 <anssik> anssik: Application Lifecycle and Events was moved to be part of the Runtime discussion on Thu morning
15:33:13 <anssik> [discussing potential TF topics]
15:33:52 <thinker> thinker has joined #sysapps
15:33:57 <mounir> Claes: Sockets API discussions
15:34:06 <mounir> mounir: runtime/packaged apps discussions
15:34:27 <zkis> zkis: interested on DataStore used in Contacts, Messaging and Telephony
15:34:41 <zkis> also on Runtime
15:39:09 <anssik> mounir: proposal, discuss runtime today afternoon, tomorrow split into groups based on interest
15:39:25 <kenneth_> +1
15:39:30 <genelian> +1
15:39:31 <wonsuk1> +1
15:39:34 <JonathanJ1> +1
15:39:36 <spoussa> +1
15:39:40 <zkis> +1
15:40:11 <jmajnert> +1
15:40:17 <anssik> +1
15:40:44 <anssik> http://anssiko.github.io/runtime/app-lifecycle.html
15:40:49 <mounir> mounir: what do people what to discuss about runtime?
15:40:59 <mounir> anssik: I would like to discuss this proposal that we wrote
15:41:18 <mounir> ... it seems that the system messages is not that great
15:41:24 <mounir> ... so we should find a way to fix that.
15:41:35 <mounir> ... We call that in our proposal "persistent events".
15:42:01 <mounir> ... This is describing an event page model.
15:42:16 <mounir> ... It is a model with multiple windows and takes care of race conditions when you have multiple windows.
15:43:03 <mounir> ... We wrote down this proposal to cover use cases that are not covered by the current proposal.
15:43:52 <mounir> ... This is currently focused on the packade apps use case but we should keep in mind of the browser use case.
15:44:23 <mounir> ... So mounir, you mentioned issues about design issues in having event pages in the browser, could you share that we us?
15:46:28 <galindo> galindo has joined #sysapps
15:47:50 <thinker> https://developer.mozilla.org/en-US/docs/WebAPI/Simple_Push ?
15:49:08 <marcosc> anssik: I would like to provide some background on the use cases
15:49:28 <marcosc> ... for the group
15:49:30 <mounir> Topic: Application Lifecycle and Events
15:50:49 <Daniel_Samsung> Daniel_Samsung has joined #sysapps
15:50:59 <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.
15:52:01 <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.
15:52:38 <marcosc> ... so, like an email application that boots up, sends and email and shuts down without UI.
15:53:13 <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.
15:55:15 <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).
15:55:15 <marcosc> 
15:55:50 <marcosc> anssik: as mounir already pointed out, this need to rationalised to web developers as this is a bit of a foreign concept.
15:56:23 <marcosc> anssik: so in the model, a decision can be made as to wether the UI should be shown to the user.
15:57:29 <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.
15:57:54 <marcosc> dsr: so should it be a script that decides this?
15:58:18 <marcosc> anssik: so yeah, we are looking into that - it if should be a document or a script.
15:59:02 <marcosc> kenneth: so it could be a full document, but potentially with some limitations. This document would be able to detect particular lifecycle events.
15:59:40 <Daniel_Samsung> rrsagent, draft minutes
15:59:40 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/28-sysapps-minutes.html Daniel_Samsung
15:59:45 <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.
16:00:20 <marcosc> marcosc: debugging workers is hell
16:00:29 <marcosc> anssik: yes, it's complicated and the tools are not there.
16:01:08 <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.
16:01:46 <marcosc> kenneth_: in Chrome, it's a browser instance but not showing any UI.
16:02:05 <marcosc> mounir: so why not use a worker?
16:02:17 <marcosc> kenneth_: because you don't get access to the platform APIs.
16:02:31 <marcosc> anssik: if you start with workers, you don't get any platform APIs
16:03:16 <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.
16:03:34 <lgombos> q+
16:03:49 <Claes> q-
16:04:05 <wonsuk1> q?
16:04:28 <mounir> q?
16:04:33 <mounir> ack lgombos
16:04:33 <marcosc> kenneth_: the problem is that you don't have access to APIs like geo
16:05:13 <marcosc> lgombos: I think this one of the key issues - though I don't have a strong stance on this.
16:06:22 <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.
16:06:56 <marcosc> anssik: my take away from this is that we agree on the use case, but not so much the solution.
16:07:21 <marcosc> kenneth_: we need more than just a worker - but we should probably seek more feedback from the web community.
16:07:33 <marcosc> anssik: we need to write code and experiment here
16:10:10 <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
16:11:09 <dsuwirya> q+
16:11:39 <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).
16:11:56 <marcosc> mounir: there is no technical reason why we can't add XHR to workers
16:12:37 <mounir> q?
16:13:05 <mounir> ack dsuwirya
16:13:35 <marcosc> anssik: one use case that would require a document would be to create document fragments in one page and pass them to another.
16:13:59 <jungkees> Within worker context, we cannot fully make use of xhr request, e.g. cannot set response type to document, etc.
16:14:21 <jungkees> So, in terms of that example, worker context has limitations.
16:14:41 <marcosc> dsuwirya: I think this is an interesting feature - but is it the intention to provide some kind of services or "middleware" for applications?
16:15:22 <marcosc> dsuwirya: on Android, we can build such things on Android.
16:16:05 <marcosc> kenneth_: you can probably do that on Google's app platform using inter app communication - but not so much with this proposal.
16:16:42 <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.
16:16:49 <thinker> q+
16:17:23 <wonsuk1> q?
16:17:42 <tantek> tantek has joined #sysapps
16:17:43 <wonsuk1> ack thinker
16:20:28 <dsr> q+
16:23:01 <Dong-Young> q+
16:25:00 <marcosc> Dong-Young: I don't see the reason as to why we would have a single entry point?
16:25:11 <mounir> s/Dong-Young:/thinker:/
16:25:49 <marcosc> thinker: we don't need every application to have a single entry point.
16:26:51 <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.
16:27:36 <chaals> chaals has joined #sysapps
16:27:55 <chaals1> chaals1 has joined #sysapps
16:28:12 <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.
16:28:44 <marcosc> thinker: it still has potential issues - like more memory usage, etc.
16:29:38 <mounir> q?
16:30:01 <mounir> ack dsr
16:30:11 <marcosc> [discussion about background vs foreground pages... etc]
16:32:35 <chaals1> rrsagent, draft minutes
16:32:35 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/28-sysapps-minutes.html chaals1
16:33:05 <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.
16:33:26 <gmandyam> gmandyam has joined #sysapps
16:33:55 <mounir> q?
16:34:02 <mounir> ack Dong-Young
16:34:08 <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.
16:34:13 <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.
16:34:24 <marcosc> marcosc: better than using cross-doc messaging, which is hard.
16:36:12 <marcosc> ??: 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.
16:36:32 <mounir> s/??:/Dong-Young:/
16:36:49 <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.
16:38:50 <marcosc> anssik: we can talk offline about it a bit more
16:39:28 <marcosc> anssik: The next one is "Termination sequence"
16:40:44 <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.
16:41:50 <wonsuk1> q?
16:42:19 <marcosc> anssik: the final one is creating windows
16:43:18 <marcosc> anssik: we current have window.open, but it's not quite what we need... it has a lot of legacy baggage.
16:43:50 <marcosc> kenneth_: we are still working on the use cases for this
16:44:27 <marcosc> anssik: if you have worked with window.open, it's synchronous, etc.
16:44:48 <marcosc> mounir: it's not really synchronous
16:45:03 <marcosc> anssik: we should look at the requirements
16:45:22 <marcosc> anssik: I won't read them out loud, but I encourage everyone to take a look at them
16:46:27 <marcosc> anssik: please digest this idea over lunch and we will look the API proposal after lunch.
16:46:33 <mounir> [lunch break]
16:47:21 <chaals1> rrsagent, draft minutes
16:47:21 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/28-sysapps-minutes.html chaals1
16:52:42 <Daniel_Samsung_> Daniel_Samsung_ has joined #sysapps
16:55:07 <lgombos_> lgombos_ has joined #sysapps
17:09:00 <kjwallis> kjwallis has joined #sysapps
17:21:23 <kjwallis> kjwallis has left #sysapps
17:33:40 <lgombos_> lgombos_ has joined #sysapps
17:46:41 <marcosc> marcosc has joined #sysapps
17:46:51 <timeless> scribe: Josh_Soref
17:46:53 <timeless> scribenick: timeless
17:47:01 <timeless> topic: Environment
17:47:08 <timeless> mounir: ehsan is trying to fix the A/C
17:47:14 <timeless> ... (by finding someone to fix it)
17:47:37 <timeless> topic: Application Lifecycle and Events
17:47:56 <timeless> anssik: should we go over the requirements?
17:48:14 <room> http://anssiko.github.io/runtime/app-lifecycle.html#requirements
17:48:41 <timeless> [ anssik enumerates UCs/Requirements ]
17:48:45 <kjwallis_> q+
17:49:14 <JonathanJ1> JonathanJ1 has joined #sysapps
17:49:17 <timeless> 1. An application (e.g. a background service) must be able to run without visible user interface.
17:49:38 <timeless> anssik: the first requirement is from the perspective of packaged applications
17:49:54 <timeless> ... we should try to make this work for regular web content
17:49:55 <wonsuk1> q?
17:49:57 <mounir> ack kjwallis_
17:50:13 <timeless> kjwallis_: when you say application/background service
17:50:18 <timeless> ... what UCs were you considering here?
17:50:34 <timeless> ... I see ... "a persistent service", like location tracking
17:50:43 <timeless> ... or "an event based service"
17:50:54 <timeless> ... I think both UCs are valid but they might have different Requirements
17:51:01 <timeless> ... what informed these requirements
17:51:11 <timeless> kenneth_: when i plug in my SD card, i want to be launched
17:51:15 <timeless> ... and start a photo importer
17:51:22 <timeless> ... it could also be a polling app
17:51:39 <timeless> kjwallis_: i just wonder if different platforms might impose different restrictions based on what they want to do
17:51:51 <timeless> ... BB10 imposes different restrictions on what could be done in the background
17:51:59 <timeless> kenneth_: if you're allowed to do this, you might have to install it
17:52:32 <timeless> kjwallis_: an would be registered for this
17:52:36 <timeless> ... does the app have to be run first?
17:52:44 <timeless> ... would there be a way to do this from the manifest
17:52:50 <timeless> kenneth_: in chrome there's an OnInstalled event
17:52:55 <timeless> ... maybe run w/ limitations
17:53:01 <timeless> anssik: other questions?
17:53:20 <timeless> 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.
17:53:33 <lgombos_> lgombos_ has joined #sysapps
17:54:23 <wonsuk1> q?
17:54:31 <timeless> mounir: the runtime should be able to close the application even if the UI is visible
17:54:37 <timeless> anssik: that isn't preferred
17:54:45 <timeless> mounir: we shouldn't define things this way
17:54:55 <timeless> ... just say "the runtime should be able to close an application at any time"
17:55:29 <timeless> 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.
17:56:02 <timeless> marcosc: we faced the same problem in Responsive images
17:56:05 <timeless> ... you don't actually know
17:56:18 <timeless> ... you need an explicit way to know when your UI is completely layed out
17:56:49 <timeless> marcosc: when this discussion happened on whatwg for ready
17:56:59 <timeless> anssik: our model... the developer is in control
17:57:12 <timeless> ... you invoke window.show() when your business logic is ready
17:57:18 <timeless> kenneth_: i want to create a window, check screen size
17:58:01 <mounir> q+
17:58:14 <timeless> ... when it's "ready", i show it
17:58:27 <timeless> mounir: i tried some experiments using chrome apps
17:58:36 <timeless> ... i saw what you demod
17:58:42 <wonsuk1> ack mounir
17:58:44 <timeless> ... having to open a window when you launch an app
17:58:46 <timeless> ... it's silly
17:58:50 <timeless> ... everyone wants a window
17:58:58 <timeless> anssik: i had this discussion with kenneth_
17:59:04 <timeless> ... i agree w/ mounir
17:59:11 <timeless> ... but we have to make sacrifices
17:59:18 <timeless> ... we have to serve all UCs
17:59:31 <timeless> mounir: we can have a way to say in the manifest
17:59:35 <timeless> ... "i want this page"
17:59:42 <timeless> ... or "i want this script to run w/o a page"
17:59:52 <timeless> ... if you have to write 10 lines of JS
17:59:58 <timeless> ... this is a waste of time...
18:00:05 <timeless> kenneth_: it's a difficult situation
18:00:17 <timeless> ... we wanted it to be hard for people to create applications
18:00:20 <timeless> ... with bad UX
18:00:29 <timeless> ... this is the position apple takes w/ iOS
18:00:41 <timeless> mounir: i don't see how your proposal improves UX
18:00:46 <timeless> ... you're making life harder for everyone
18:00:52 <timeless> ... and expecting people to do the right thing
18:01:02 <opoto> +1 w/ mounir
18:01:04 <timeless> ... everyone knows that if you expect people to do the right thing on the web
18:01:07 <timeless> ... it won't work
18:01:12 <timeless> kenneth_: i need to create a window
18:01:13 <dsr> q+
18:01:23 <timeless> ... if i didn't create specify hidden
18:01:25 <timeless> ... it will show up
18:01:33 <timeless> ... this gives you the ability to show a splash screen
18:01:37 <timeless> ... you can do it, it's possibl
18:01:42 <timeless> s/possibl/possible/
18:01:45 <timeless> mounir: i understand
18:01:50 <timeless> ... your point of view
18:02:01 <timeless> ... but you're being very sophisticated
18:02:11 <timeless> ... as a developer, i was very surprised that i had to create that file
18:02:15 <timeless> ... just to get a window to show up
18:02:18 <timeless> q?
18:02:20 <timeless> q+ Josh_Soref
18:02:30 <timeless> ... if you want something very complex w/ system messages, you can do that
18:02:41 <timeless> kenneth_: Chrome allows you to use JS files and XML files
18:02:54 <timeless> ... it could be possible for you to give it an html file and have it just show it in a window
18:02:58 <mounir> ack dsr
18:03:04 <timeless> dsr: very simple
18:03:09 <timeless> ... from the developer's PoV
18:03:15 <timeless> ... window:html or background:somescripts
18:03:23 <timeless> ... there are lots of complication in Chrome extensions
18:03:40 <timeless> ... an implicit html
18:03:44 <timeless> ... i think it should be really simple
18:03:49 <timeless> ... window:htmlfile
18:03:54 <timeless> ... or backgroud:script
18:03:59 <timeless> ... keep it simple
18:04:11 <timeless> marcosc: the UC they have is that you do it imperatively
18:04:15 <JonathanJ1> JonathanJ1 has joined #sysapps
18:04:16 <wonsuk1> q?
18:04:25 <timeless> ... you're right it should be possible to do it declaratively
18:04:49 <timeless> <html><head><script lazy></head><body><img src=splash>
18:04:57 <timeless> dsr: in Mozilla's push proposal
18:05:07 <timeless> ... you register different context for different contexts
18:05:23 <timeless> marcosc: there are different ways to skin this cat
18:05:30 <timeless> ... but this can definitely be put into the manifest
18:05:33 <timeless> ... we have starturl
18:05:38 <timeless> anssik: launchpath
18:05:44 <timeless> marcosc: it could be an object
18:05:51 <timeless> ... it could have a property `hidden`
18:05:59 <mounir> q?
18:06:00 <mounir> q+
18:06:48 <mounir> timeless: you can already handle a splash screen today, you do not require some complicated thing to know when you are ready
18:07:09 <mounir> ... you can use CSS to make an image fit the entire screen
18:07:12 <mounir> ... this is not required
18:07:12 <wonsuk1> ack Josh
18:08:44 <mounir> ... for everything else, you might want to use the manifest with different entry points, like startup or events
18:08:45 <timeless> s/mounir/scribe/
18:08:46 <timeless> s/mounir/scribe/
18:08:47 <timeless> s/mounir/scribe/
18:08:47 <marcosc> http://marcoscaceres.github.io/playground/splashscreens/
18:08:48 <timeless> s/mounir/scribe/
18:09:05 <timeless> mounir: i was going to say the same thing
18:09:06 <mounir> ack mounir
18:09:08 <dsr> s/register different context/register different html files/
18:09:38 <timeless> mounir: we had a long fight internally about a splash screen
18:09:41 <timeless> ... in the manifest
18:09:54 <kjwallis_> q+
18:09:56 <timeless> marcosc: this holds until it loads content and then goes
18:10:13 <timeless> kenneth_: 2s 5s... it could be 200ms
18:10:18 <timeless> marcosc: we need to gather numbers
18:10:28 <timeless> ... for mozilla, the UX guys said "we need splash screens"
18:10:36 <timeless> ... we asked how long does it take to load your content
18:10:38 <timeless> ... and it was 100ms
18:10:49 <timeless> ... 100ms on this device, it isn't noticable
18:10:59 <timeless> ... you click, it does an animation, and loads it
18:11:08 <timeless> ... on Cordova, the startup dance takes i don't know how long
18:11:18 <lgombos_> q+
18:11:30 <timeless> mounir: if the runtime knows it will take a long time to open the app
18:11:41 <timeless> ... we had the same issue w/ Firefox for Android
18:11:47 <timeless> ... have a runtime that can open apps
18:11:51 <timeless> ... it's quite slower on Firefox OS
18:12:01 <timeless> ... we could simply have a generic splash screen made by the runtime
18:12:08 <timeless> ... it could say "this is starting"
18:12:19 <timeless> ... most people see this every day on iOS
18:12:25 <timeless> s/iOS/OSX/
18:12:29 <timeless> ... the app just bounces
18:12:37 <timeless> ... and when the app is ready, OS X shows the window
18:12:45 <timeless> ... we could do that same behavior
18:12:54 <timeless> kenneth_: i agree that i don't want us to specify a splash screen api
18:13:02 <wonsuk1> q?
18:13:02 <timeless> ... OS X doesn't create a white window and wait five seconds
18:13:18 <timeless> ... i want to make sure it's possible to make it seem like it has
18:13:26 <timeless> mounir: you'll end up w/ the opposite result
18:13:35 <timeless> ... what takes time is creating process, loading resources
18:13:38 <timeless> ... you're on Firefox OS
18:13:42 <timeless> ... you deal w/ zip file
18:13:44 <timeless> ... create process
18:13:52 <timeless> ... this takes time, this is the longest part
18:13:59 <timeless> ... when you can run that script, you're mostly done
18:14:07 <timeless> ... the time you win by saying "that window is going to load"
18:14:14 <timeless> ... to make it look like it's immediate
18:14:16 <timeless> ... it's the opposite
18:14:21 <timeless> ... say i'm bouncing on OS X
18:14:26 <timeless> ... the app will no longer be bouncing
18:14:29 <timeless> ... but i'll see nothing
18:14:34 <timeless> ... and then i'll see the app ready
18:14:46 <timeless> ... the same thing when Chrome would show an image of the Chrome UI
18:14:52 <timeless> ... and then the Chrome UI would load
18:14:57 <timeless> ... a common behavior nowaday
18:15:02 <timeless> q?
18:15:12 <timeless> kenneth_: i think we can remove that UC
18:15:14 <timeless> ack kjwallis_
18:15:18 <timeless> kjwallis_: the splash screen UC
18:15:23 <timeless> ... i think the platform will have to handle that
18:15:26 <timeless> ... as mounir was saying
18:15:35 <timeless> ... whether the platform owns or wants to pass it on to the developer
18:15:40 <timeless> ... i had more to say, but you covered it already
18:15:47 <timeless> ... if the platform wants to pass it on to the developer
18:15:58 <timeless> ... there would be some way to define extensions to the manifest
18:16:05 <timeless> ... i don't think the manifest needs to cover it
18:16:13 <timeless> ... but the platform might want to extend it
18:16:16 <room> q?
18:16:23 <timeless> marcosc: "yes"
18:16:28 <timeless> [ laughter ]
18:16:32 <timeless> marcosc: we went around 2 months
18:16:38 <timeless> ... mounir, myself, chaals1
18:16:44 <timeless> ... that's one of the drawbacks of JSON
18:16:49 <timeless> ... you can shove things anywhere
18:16:54 <timeless> ... w/o a way to control extensibility
18:16:59 <timeless> ... we don't have a good way
18:17:05 <timeless> ... we have proposals, they're fairly ugly
18:17:07 <Claes> Claes has joined #sysapps
18:17:11 <timeless> ... we know cordova made a bunch of extensions
18:17:16 <timeless> ... blackberry made a bunch of extensions
18:17:26 <timeless> ... we considered banning getting to the manifest file altogether
18:17:42 <timeless> ... we could add a data member, not for vendor extensions, but for app specific data
18:17:47 <timeless> ... it isn't easy
18:18:13 <timeless> mounir: there was a time when people used prefixes
18:18:16 <timeless> ... but prefixes are bad
18:18:20 <timeless> ... we might lose interop
18:18:29 <timeless> ... we might end up w/ sniffing if people can read the manifest
18:18:37 <timeless> ... how to allow w/o messing w/ interop
18:18:42 <timeless> ack lgombos_
18:18:47 <timeless> lgombos_: not sure if splashscreen is gone
18:18:48 <room> q?
18:18:53 <timeless> ... if there are performance requirements
18:18:57 <timeless> ... we should capture that
18:19:11 <timeless> ... splashscreen is an example, if we have a requirement
18:19:19 <timeless> ... we should define what the constraint is -- maybe only static images
18:19:25 <timeless> ... but it's a general comment
18:19:34 <timeless> mounir: you can only say it's a performance issue
18:19:39 <timeless> ... if you have implementation experience
18:19:48 <timeless> ... you shouldn't call something a performance issue w/o data
18:20:00 <timeless> 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.
18:20:14 <wonsuk1> q?
18:20:24 <timeless> anssik: example is an application that opens multiple windows
18:20:26 <timeless> ... it's terminated
18:20:33 <timeless> ... it should be able to resume it's previous state
18:20:40 <timeless> kenneth_: it should be possible for the application
18:20:48 <timeless> ... if it wanted to, to restore its previous state
18:20:57 <timeless> mounir: how is that not doable nowadays?
18:21:07 <timeless> ... on the web
18:21:12 <timeless> ... every application can be closed at any time
18:21:15 <timeless> ... you can start them again
18:21:21 <timeless> ... how much is this something we need to support
18:21:27 <timeless> ... and something they know how to do
18:21:35 <timeless> marcosc: we know the strategies used to do this
18:21:42 <timeless> ... people use URLs to reconstruct the application
18:21:50 <timeless> ... serializing state and building back up
18:22:01 <timeless> mounir: more general comment about terminate event
18:22:04 <timeless> ... i understand the idea
18:22:10 <timeless> ... and where it's coming from
18:22:15 <timeless> ... we don't have it on the web
18:22:20 <timeless> ... it doesn't break
18:22:25 <timeless> ... they might get onclose
18:22:31 <timeless> ... is there a real UC
18:22:37 <timeless> q+ Josh_Soref
18:22:43 <timeless> anssik: distinction between a web page closing
18:22:46 <timeless> ... and the user closing
18:22:54 <timeless> ... for apps the system can terminate w/o user consent
18:23:04 <timeless> ... there's an expectation that it can close
18:23:10 <timeless> marcosc: because there's no url to go back to
18:23:14 <timeless> ... on android
18:23:18 <timeless> ... they serialize the application
18:23:21 <timeless> kenneth_: chrome apps
18:23:30 <timeless> ... it calls terminate and runs for at most 1s
18:23:43 <timeless> mounir: wonder how much it isn't a design flaw to say there's a terminate event
18:23:50 <timeless> ... Firefox for Android was so slow to save its state
18:23:56 <timeless> ... that it was killed by the system
18:24:00 <timeless> ... that when you opened it again
18:24:06 <timeless> ... it wasn't in the same state
18:24:13 <timeless> ... a simple solution is to save your state as you go
18:24:16 <timeless> ... if at any time you're closed
18:24:19 <timeless> ... you can resume
18:24:27 <timeless> ... then having a terminate event will push applications to be lazy
18:24:40 <timeless> ... saving only when they're killed
18:24:42 <timeless> Josh_Soref: +1
18:24:49 <timeless> dsr: so this is about developer guidelines
18:24:59 <timeless> kenneth_: we added a note in the spec that you should save your state once in a while
18:25:08 <timeless> ... with a system app, you might be connecting to hardware
18:25:14 <timeless> ... it might be useful to do bluetooth
18:25:15 <timeless> q?
18:25:22 <timeless> mounir: not sure how the system can not help
18:25:29 <timeless> ... if it knows you're using bluetooth, it can clean up
18:25:36 <timeless> kenneth_: maybe you can control order of closing
18:25:38 <timeless> mounir: i'm not against
18:25:46 <timeless> ... i'm saying the arguments aren't strong enough
18:25:51 <timeless> ... if when we work on bluetooth
18:25:59 <timeless> ... someone says "there's no way to handle bluetooth"
18:26:11 <timeless> ... for now, the UC for saving state is wrong
18:26:16 <timeless> ... we're pushing people to do the wrong thing
18:26:24 <timeless> kenneth_: we can probably come up w/ better UCs
18:26:31 <timeless> mounir: we shouldn't try to come up w/ better UCs
18:26:39 <timeless> ... we should remove it
18:26:45 <timeless> ... and only add it when someone gives us a UC
18:26:47 <timeless> kenneth_: i agree
18:26:50 <room> q?
18:26:50 <mounir> q?
18:26:53 <timeless> ... and i don't mind removing it
18:26:59 <timeless> ack Josh_Soref
18:27:21 <mounir> timeless: first of all, I agree with mounir, I use mobile devices, I tend to drop them and the battery pops out
18:27:22 <sicking> sicking has joined #sysapps
18:27:38 <mounir> ... and when I put the battery back, the apps I was running don't start again
18:27:44 <mounir> ... the reason is that they don't get a terminate event
18:27:55 <mounir> ... same way, I sometimes force the system to reboot
18:28:15 <Zakim> +[Mozilla.a]
18:28:20 <Zakim> -[Mozilla]
18:28:21 <Zakim> +[Mozilla]
18:28:32 <sicking> Zakim: Mozilla.a is me
18:28:39 <wonsuk1> q?
18:28:42 <mounir> anssik: the requirement is more abstract that that
18:28:45 <timeless> Zakim, Mozilla.a is sicking
18:28:45 <Zakim> +sicking; got it
18:30:02 <mounir> timeless: bluetooth devices have a timeout, I walk away from them and they survive
18:30:13 <mounir> ... the right design is to ask ppl to save state as they go
18:30:26 <mounir> ... It could be a non-normative thing.
18:30:42 <timeless> s/timeless/Josh_Soref/
18:30:47 <timeless> s/mounir/scribe/
18:30:48 <timeless> s/mounir/scribe/
18:30:48 <timeless> s/mounir/scribe/
18:30:57 <timeless> 5.  After being launched, an application must be able to execute scripts to recreate its state before recreating the actual user interface.
18:31:05 <timeless> anssik: probably some repetition w/ #3
18:31:19 <timeless> 6.  An application must be able to show a different user interface given how the app was launched.
18:31:25 <timeless> 
18:31:25 <timeless>   o  For example, if launched as a photo picker should not show the default application window, but instead create a special purpose user interface.
18:32:03 <timeless> mounir: this is clearly a UC we have for Web Activities
18:32:13 <timeless> ... we let you associate an html page w/ a system message
18:32:22 <timeless> ... if the email app is opened by the email activity
18:32:28 <timeless> ... we show the compose page
18:33:17 <room> q?
18:33:32 <timeless> ... the system message has the object with the activity name
18:34:07 <timeless> 7.  The runtime must provide a mechanism to prevent an application from being launched unneededly.
18:34:40 <timeless> Google says unneededly has About 21,200 results (0.19 seconds)
18:34:46 <timeless> kenneth_: UC is System Events
18:34:53 <timeless> ... get USB connected
18:35:04 <timeless> ... instead of forcing filtering on app itself
18:35:15 <timeless> ... you have the ability to create a filtering mechanism that the runtime does
18:35:29 <timeless> mounir: how is this different from point 1
18:35:37 <timeless> kenneth_: i get a usb connected to n
18:35:41 <timeless> ... and only in host mode
18:35:48 <timeless> mounir: how is this related to
18:36:25 <timeless> ... this spec shouldn't define stuff for USB API
18:36:44 <timeless> ... it's a requirement for other APIs to not file events needlessly
18:36:54 <timeless> ... we have a lot of events that are sent too often
18:37:08 <timeless> ... we're asked to send events less often to avoid waking up the device
18:37:10 <room> q?
18:37:23 <timeless> 8.  The runtime must provide a one entry point for window creation to prevent race conditions (see #100).
18:39:27 <timeless> anssik: we should address this
18:39:42 <timeless> 9.  The application must be able to create a window and have it laid out correctly with the right dimensions before being shown.
18:40:06 <timeless> marcosc: you can create a virtual viewport
18:40:09 <timeless> ... and try laying things out
18:40:19 <timeless> ... even when you throw it up on the screen, it might change conditions
18:40:28 <timeless> anssik: you're talking about adaptive design?
18:40:36 <timeless> marcosc: windows + laid out correctly
18:40:40 <timeless> q+ Josh_Soref
18:40:53 <timeless> q+ Josh_Soref to ask about my screen resolution changing when i "attach" a projector
18:41:00 <timeless> kenneth_: you can use Media Queries on IE
18:41:09 <timeless> marcosc: this comes back to knowing when the layout is "Done"
18:41:13 <timeless> ... we don't have that today
18:41:21 <timeless> kenneth_: in chrome, you know
18:41:39 <timeless> marcosc: there's a bug filed
18:41:47 <timeless> ... it came out of lazy loading that you do want these events
18:41:51 <timeless> ... they're valid UCs
18:41:56 <timeless> ... not sure they should be covered here
18:42:00 <timeless> ... the TAG has talked about it
18:42:15 <wonsuk1> q?
18:42:21 <timeless> mounir: it's a larger web issue
18:42:29 <timeless> ... it's something applications really want, but not this spec
18:42:33 <timeless> kenneth_: this was a brain dump
18:42:41 <timeless> mounir: but you listed it as a requirement of the life cycle spec
18:42:49 <timeless> ack j
18:42:49 <Zakim> Josh_Soref, you wanted to ask about my screen resolution changing when i "attach" a projector
18:42:50 <room> q?
18:42:51 <mounir> ack Josh_Soref
18:43:35 <mounir> timeless: so, I start an application and then I manage to change my screen (like external display)
18:43:41 <mounir> ... so the screen resolution changes
18:43:50 <mounir> ... then you can't assume the screen resolution will never change, it is naive
18:44:14 <mounir> marcosc: you are right in the larger picture
18:44:27 <mounir> [showing the splash screen example]
18:44:54 <mounir> [showing that if you scroll down, the content is being shown after the splash screen]
18:45:29 <mounir> 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
18:46:03 <mounir> ... you can work around it but you should not have to be so hacky about it
18:46:05 <wonsuk1> q?
18:46:53 <timeless> s/timeless/Josh_Soref/
18:46:59 <timeless> s/mounir/scribe/
18:47:00 <timeless> s/mounir/scribe/
18:47:01 <timeless> s/mounir/scribe/
18:47:06 <timeless> s/mounir/scribe/
18:47:07 <timeless> s/mounir/scribe/
18:47:07 <timeless> s/mounir/scribe/
18:47:08 <timeless> s/mounir/scribe/
18:47:09 <timeless> s/mounir/scribe/
18:47:21 <timeless> 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.
18:48:04 <timeless> kenneth_: we'd like prefiltering for events
18:48:13 <timeless> spoussa: this is the duplicate of the previous one
18:48:18 <timeless> marcosc: sounds like the drop box UC
18:48:48 <timeless> ... when i plug in a paired phone, it syncs when i plug in
18:48:53 <timeless> ... but for another phone it asks
18:48:56 <timeless> mounir: no
18:49:08 <timeless> ... it's for saying "when i attach a phone tell me"
18:49:16 <timeless> ... but that's specific to the spec
18:49:18 <timeless> ... not here
18:49:27 <wonsuk1> q?
18:49:46 <timeless> Josh_Soref: you're talking about best practices for writing other specs
18:50:01 <timeless> anssik: this was a subrequirement for 7
18:50:08 <timeless> marcosc: it should really go to the usb api
18:50:13 <timeless> mounir: or other apis
18:50:20 <timeless> ... it's good to keep it in mind
18:50:23 <timeless> ... apis send events
18:50:27 <timeless> ... but if events wake an app
18:50:34 <timeless> ... you might do only when needed
18:51:04 <timeless> q+ Josh_Soref to ask if 5.1 can solve the exit() problem by only allowing exit from it
18:51:17 <timeless> mounir: never assume implementers did something for a good reason
18:51:23 <timeless> kenneth_: sure, we can ask them
18:51:29 <timeless> ...  i assume they did it because it was easier
18:51:40 <timeless> anssik: if we start w/ a main worker
18:51:43 <timeless> ... the appstart-worker
18:51:50 <timeless> ... which apis should be exposed to this context
18:51:55 <timeless> ... if we start w/ document
18:52:01 <timeless> ... then we think about what's not working
18:52:07 <timeless> ack Josh_Soref
18:52:07 <Zakim> Josh_Soref, you wanted to ask if 5.1 can solve the exit() problem by only allowing exit from it
18:52:10 <room> q?
18:52:55 <timeless> marcosc: maybe
18:53:35 <room> http://anssiko.github.io/runtime/app-lifecycle.html#infrastructure
18:53:58 <timeless> anssik: this section is even rougher than the UCs
18:54:05 <timeless> ... a Work In Progress
18:54:16 <timeless> ... Application Events -- Life Cycle events
18:54:42 <timeless> ... a reason is passed to the launch event
18:54:52 <timeless> ... pending-evnet,scheduled, other
18:54:57 <timeless> ... to be fleshed out
18:55:08 <gmandyam> q+
18:55:30 <timeless> anssik: "other" is used for the user trying to open the app normally
18:56:32 <timeless> gmandyam: when you talk about persistent events
18:56:37 <mounir> q+ to ask when the launch event is sent exactly (examples)
18:56:42 <mounir> ack gmandyam
18:56:49 <timeless> ... for catastrophic/high priority
18:56:59 <timeless> ... how do you make sure the handler is invoked
18:57:03 <timeless> ... you have battery-low-event
18:57:44 <timeless> ... how do you ensure things are triggered immediately and not in a queue?
18:57:52 <timeless> kenneth_: the way it works in Chrome
18:58:00 <timeless> ... the first thing you do at launch is resubscribe to events
18:58:07 <timeless> ... and when that goes out of scope, you get the actual events
18:58:28 <timeless> gmandyam: maybe battery isn't a good example
18:58:36 <timeless> ... say you have a 1xEVDO thing up
18:58:41 <timeless> ... you get an incoming-voice-page
18:58:41 <lgombos_> q+
18:58:46 <timeless> ... the data connection should be interrupted
18:59:00 <timeless> ... i don't think most EVDO operators are deploying devices
18:59:14 <timeless> ... the application should be able to work off saved data
18:59:22 <timeless> kenneth_: if an application is running
18:59:29 <timeless> ... the application is invoked immediately
18:59:34 <timeless> ... if it wasn't running
18:59:46 <timeless> ... it's launched, the app registers its handlers, and then gets the event
18:59:56 <timeless> ... the event lets the application shortcut building the UI
19:00:09 <Zakim> -sicking
19:00:19 <sicking> sorry guys, gotta head out to lunch
19:00:25 <timeless> gmandyam: i'm asking if the event is so high priority, can it jump the queue
19:00:32 <wonsuk1> q?
19:00:34 <timeless> kenneth_: we haven't worried about that
19:01:08 <timeless> anssik: persistent events aren't like dom events
19:01:14 <timeless> ... they live past the document lifespan
19:01:20 <timeless> ... we have a bunch of notes
19:01:31 <timeless> ... requiring apps to resubscribe at launch
19:01:34 <timeless> ... there are alternatives
19:01:49 <mounir> ack mounir
19:01:49 <Zakim> mounir, you wanted to ask when the launch event is sent exactly (examples)
19:02:04 <timeless> mounir: when do you expect to receive the launch event
19:02:13 <timeless> anssik: the launch sequence
19:02:25 <timeless> ... every time it's being launched (after termination) or for the first time
19:03:04 <timeless> ... My app was running, it was killed, and it's launched from the task scheduler
19:03:10 <timeless> ... is it given the launch event?
19:03:11 <timeless> anssik: yes
19:03:21 <timeless> mounir: how does the app know if the user opened it
19:03:47 <timeless> ... if launch only means that the user launched it
19:04:02 <timeless> [ scribe can't follow ]
19:04:23 <timeless> kenneth_: since you're killed
19:04:31 <timeless> ... you have to resubscribe to your events at launch
19:04:44 <wonsuk1> q?
19:04:46 <timeless> ... if you don't subscribe to events, they won't be fired/your handlers won't be called
19:04:59 <timeless> ack lgombos_
19:05:00 <room> q?
19:05:09 <timeless> lgombos_: one of the requirements/UCs discussed
19:05:19 <timeless> ... was deep linking into an application
19:05:26 <timeless> ... like adding-a-calendar-event
19:05:49 <timeless> anssik: you're asking about the UC of a picker
19:05:56 <timeless> kenneth_: we haven't looked into Web Activity integration
19:06:09 <timeless> lgombos_: deep linking UCs might be based on sending the reason in the URL
19:06:20 <timeless> ... maybe you just do #picker at the end of the url
19:06:30 <timeless> ... but maybe that could be how you handle launch reason
19:06:34 <timeless> kenneth_: we should consider that
19:06:37 <timeless> lgombos_: thanks
19:06:39 <mounir> q?
19:07:06 <timeless> anssik: Filtered Events
19:07:11 <timeless> mounir: is this coming from Chrome too?
19:07:12 <timeless> anssik: yes
19:07:30 <timeless> kenneth_: in chrome it's addListener... here it's addPersistentEventListener
19:07:41 <timeless> ... here you can even have a function
19:07:50 <timeless> ... it would be good to avoid waking up applications
19:07:53 <dsuwirya> dsuwirya has joined #sysapps
19:07:58 <timeless> anssik: this api is very un-web-like
19:08:14 <timeless> ... it should be navigator, not navigation
19:08:49 <timeless> ... the listeners only exist in the context of the main document
19:09:03 <room> q?
19:09:35 <timeless> anssik: onlaunch, onterminate, onterminatecanceled
19:10:26 <timeless> [ avoid using canceled  -- someone will misspell it ]
19:11:24 <timeless> Terminating the Application
19:11:35 <timeless> anssik: spin the event loop for UA defined amount of time
19:11:52 <timeless> ... mounir said this encourages app developers to do cleanup at terminate
19:11:58 <timeless> ... instead of persist as you go
19:12:04 <timeless> Josh_Soref: +1 to mounir
19:12:31 <timeless> TerminateCanceledEventInit
19:12:40 <timeless> anssik: if it starts cleanup, and then gets another event to start
19:12:52 <wonsuk1> q?
19:12:54 <dsr> q+ to comment on LaunchEvent
19:13:17 <timeless> anssik: i hope the UC could be reused
19:13:19 <mounir> ack dsr
19:13:19 <Zakim> dsr, you wanted to comment on LaunchEvent
19:13:24 <timeless> dsr: quick question
19:13:37 <timeless> ... can i find out which persistent event?
19:13:45 <timeless> kenneth_: it's a note we have in the document
19:14:23 <wonsuk1> q+
19:14:52 <mounir> ack wonsuk1
19:14:58 <mounir> ack wonsuk
19:14:59 <timeless> wonsuk1: what's the next step for this proposal?
19:15:04 <mounir> q+
19:15:20 <timeless> anssik: first, we need an editor
19:15:24 <timeless> ... maybe marcosc ?
19:16:11 <timeless> marcosc: we'd need a reference implementation
19:16:38 <timeless> kenneth_: we have some of this
19:16:45 <timeless> mounir: are you implementing, or using what chrome has
19:16:45 <wonsuk1> ack mo
19:16:53 <timeless> kenneth_: we're implementing, probably taking parts from chrome
19:17:31 <timeless> mounir: i think we need a spec like this
19:17:53 <timeless> ... i'm also worried that Web Apps might do Event Pages
19:17:58 <timeless> ... we should try to sync with them
19:18:05 <timeless> spoussa: did they start?
19:18:09 <timeless> mounir: no, but they might start
19:18:42 <timeless> ... even if we start, the people behind Event Pages in WebApps would move forward
19:18:45 <timeless> ... we'd lose
19:19:07 <timeless> ... I think we should change the scope to Event Pages
19:20:38 <timeless> ... i think most of the spec works fine for the web
19:20:41 <timeless> ... so focus on that
19:21:07 <mounir> q?
19:21:27 <timeless> [ Break ]
19:33:39 <galindo> galindo has joined #sysapps
19:44:47 <timeless> Topic: Dinner Plans
19:45:04 <timeless> mounir: 7pm, Le Sélect Bistro
19:45:20 <kjwallis_> Wellington street
19:45:34 <timeless> http://www.leselect.com/
19:45:35 <wonsuk1> http://www.leselect.com/
19:45:49 <timeless> s|http://www.leselect.com/||
19:45:51 <JonathanJ1> JonathanJ1 has joined #sysapps
19:45:56 <timeless> s|http://www.leselect.com/||
19:46:02 <wonsuk1> http://www.leselect.com/
19:46:15 <timeless> s|http://www.leselect.com/|-> http://www.leselect.com/ Le Sélect Bistro|
19:46:23 <timeless> topic: Runtime Spec
19:46:46 <mounir> http://www.w3.org/2012/sysapps/runtime/
19:47:18 <timeless> s|http://www.w3.org/2012/sysapps/runtime/|-> http://www.w3.org/2012/sysapps/runtime/ Runtime and Security Model for Web Applications|
19:47:29 <timeless> mounir: the reason there's no one working on that spec
19:47:32 <timeless> ... is that it's a waste of time
19:47:36 <timeless> ... it was a brain dump
19:47:42 <timeless> ... we didn't get some implementation feedback
19:47:51 <timeless> ... from a member who tried to do things in a different way
19:48:10 <timeless> ... we got nit-pick feedback about "oh, it doesn't work if you have multiple windows"
19:48:21 <timeless> ... we were expecting/what we want...
19:48:30 <timeless> ... was people w/ real experience w/ implementation/usage to say
19:48:34 <timeless> ... this is working, this isn't working
19:48:52 <timeless> ... i'm glad to see that Intel is interested in implementing something completely different
19:49:03 <timeless> ... so we could share experience
19:49:11 <timeless> ... i think the Runtime Spec should be split
19:49:35 <timeless> ... the DOMRequest is no longer needed
19:49:39 <timeless> ... we're using Promises
19:49:51 <timeless> ... the Manifest file moved to WebApps (marcosc took ownership)
19:49:57 <timeless> ... a bit will need to be defined for apps
19:50:06 <timeless> ... App Management is something that's mostly Mozilla's vision
19:50:10 <timeless> ... i'm not sure many people share it
19:51:04 <timeless> ... System Messages we want to kill
19:51:07 <timeless> ... in favor of Event Pages
19:51:17 <timeless> ... many things can be (re)moved
19:51:21 <timeless> ... to a different spec
19:51:31 <timeless> ... and many things don't seem to have interest from other parties
19:51:37 <timeless> ... we should focus on things that people have interest in
19:51:43 <timeless> ... System Message as Event Pages
19:51:50 <timeless> ... Application Lifecycle (also Event Pages)
19:51:54 <timeless> ... and Package App
19:51:59 <timeless> ... Manifest (in Web Apps)
19:52:10 <timeless> ... if we work on that, maybe we can decide what a short term goal
19:52:12 <wonsuk1> q?
19:52:19 <gmandyam> q+
19:52:27 <timeless> ... if you have an app, it could run on every runtime that implements this
19:52:42 <timeless> ... there's no chance of someone implementing all of this
19:52:54 <timeless> ... so i think we should divide it into digestible bits
19:52:57 <timeless> q?
19:53:02 <timeless> ack gmandyam
19:53:22 <timeless> gmandyam: beyond how mozilla implements this
19:53:36 <timeless> ... most os's view application manager as something that other third party apps can invoke
19:53:59 <timeless> ... how important is it for an application to get information about other app metadata?
19:54:05 <timeless> ... you can get that from a web interface
19:54:15 <timeless> ... you probably don't want to expose delete/install to third party apps
19:54:23 <timeless> ... you probably want a preinstalled app manager
19:54:59 <timeless> mounir: we wanted to make this a truly open platform
19:55:08 <timeless> ... the api is open
19:55:14 <timeless> ... so amazon could have an app store
19:55:18 <timeless> ... facebook could have an app store
19:55:25 <timeless> ... but they could only manage apps from them
19:55:32 <timeless> ... there's a way to access every app from the system
19:55:36 <timeless> ... this is...
19:55:45 <anssik> I carved out these management APIs into their own spec a while ago: http://anssiko.github.io/runtime/privileged.html
19:55:52 <timeless> ... there's a bit of management that's privileged
19:56:01 <timeless> ... for a home screen to be able to list every app
19:56:15 <timeless> gmandyam: you wouldn't want everyone to have that
19:56:19 <timeless> mounir: yeah, that's behind a pref
19:56:23 <anssik> q+
19:56:25 <anssik> q?
19:56:37 <timeless> gmandyam: with existing web services today, you've offered quite a bit to developers today
19:56:43 <timeless> ... to put up app stores
19:56:50 <timeless> ... they can use url triggered download-install
19:57:01 <timeless> ... install origin/manifest access
19:57:27 <timeless> mounir: oh, you're talking about the `interface Application`
19:57:38 <timeless> ... if you're an app store, you want to show an app has updates available
19:57:47 <timeless> gmandyam: you could possibly do that through a preinstalled app manager
19:58:33 <timeless> ... if you have an app store, you can expose that through your own content managing system
19:59:11 <timeless> gmandyam: User buys device
19:59:15 <timeless> ... installs Amazon app store
19:59:26 <timeless> ... how is the api aware of this
19:59:37 <timeless> ... whoever is deploying an app store can expose a web service to provide that information
19:59:45 <timeless> ... it can use its own api to access that information
19:59:57 <timeless> mounir: you should open an issue
20:00:04 <timeless> ... it might be easier to explain in writing
20:00:28 <timeless> gmandyam: app: is separated, manifest.json is split out
20:00:34 <timeless> ... i think this can be relegated to a NOTE
20:00:54 <timeless> mounir: this document is a FPWD
20:00:58 <timeless> ... i don't think it's going to LC
20:01:11 <timeless> ... i think it's interesting to show it as an FPWD
20:01:20 <timeless> ... to show that the group plans to specify those features
20:01:25 <timeless> q+ Josh_Soref to talk about process
20:01:37 <timeless> mounir: moving to a NOTE gives the wrong signal
20:01:54 <timeless> gmandyam: it tells you that implementers have some latitude on security/etc.
20:02:01 <timeless> mounir: all of that needs to be standardized
20:02:07 <timeless> gmandyam: there's a lot of holes
20:02:18 <timeless> ... it's clear it's going to be fine to designate as a NOTE
20:02:22 <timeless> ... and not take this to LC
20:02:28 <timeless> mounir: i agree we won't take this to LC
20:02:40 <timeless> ... but having a FPWD, we committed to working on this subject
20:02:49 <timeless> ... if we take it to a note, it means we don't care anymore
20:03:13 <timeless> gmandyam: i think we're getting into areas where implementers need to have latitude to make choices
20:03:23 <timeless> ... i don't see the point to work on a spec that won't be going to LC
20:03:29 <timeless> ... we can allow differing opinions
20:03:45 <timeless> mounir: we need to reach a common opinion
20:04:05 <timeless> gmandyam: at the end of this, we should retire the brand names, Tizen, FirefoxOS,...
20:04:09 <timeless> q?
20:04:14 <timeless> ack anssik
20:04:26 <timeless> anssik: i split out the application management apis into their own spec
20:04:28 <anssik> https://github.com/sysapps/runtime/pull/105
20:04:29 <timeless> ... months ago
20:04:37 <anssik> http://anssiko.github.io/runtime/privileged.html
20:04:51 <timeless> s|https://github.com/sysapps/runtime/pull/105|-> https://github.com/sysapps/runtime/pull/105 Split out ApplicationManagement and related sections|
20:05:01 <timeless> anssik: to make the runtime more digestible
20:05:13 <timeless> anssik: gmandyam, you were concerned about the management apis specifically
20:05:33 <timeless> ... i question the value of standardizing some apis
20:05:43 <timeless> ... if we want to standardize, i think we should be clear on the application boundary
20:05:54 <timeless> ... i think they should be defined where the security boundary
20:05:55 <timeless> gmandyam: +1
20:06:11 <timeless> anssik: mounir, what do you think about this?
20:06:28 <timeless> mounir: this is a good example of what i mean by people tend to nitpick the spec
20:06:33 <timeless> ... app management isn't the main thing in the spec
20:06:45 <timeless> ... i don't think it's worth spending our time discussing is this useful
20:06:53 <timeless> ... mozilla has a good reason for having this there
20:06:59 <timeless> ... we want multiple marketplaces
20:07:04 <timeless> ... but people mostly don't like that idea
20:07:06 <timeless> ... if we remove that
20:07:16 <timeless> ... it doesn't change the general gist of the spec
20:07:26 <timeless> anssik: i think we're indifferent on what happens to those part
20:07:29 <timeless> ... drop or carve out
20:07:38 <timeless> Zakim, who is on the call?
20:07:38 <Zakim> On the phone I see [Mozilla]
20:07:45 <timeless> q?
20:07:57 <timeless> mounir: i still believe it's important to have it
20:08:06 <timeless> ... if someone has a solution for multiple marketplaces w/o exposing those apis
20:08:23 <timeless> anssik: is  it easier to organize them into another spec because of the security spec
20:08:32 <timeless> mounir: you only access apps you installed
20:08:49 <timeless> ... the marketplace application only has access to apps it itself has installed
20:08:54 <timeless> ... which reduces the security issues
20:09:06 <timeless> q?
20:09:15 <timeless> ack Josh_Soref
20:09:15 <Zakim> Josh_Soref, you wanted to talk about process
20:10:46 <timeless> Josh_Soref: in DAP, we tried to "SHELVE" things
20:10:50 <timeless> ... to indicate "we aren't working on this"
20:11:15 <timeless> ... 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"
20:12:09 <anssik> an example of a shelved spec: https://dvcs.w3.org/hg/dap/raw-file/default/contacts/Overview.html
20:12:58 <timeless> ... a big banner at the top of a document doesn't work
20:13:13 <timeless> ... you actually have to publish to /TR/-NOTE- space
20:13:36 <gmandyam> Another example of a spec that has been transitioned to a note: http://www.w3.org/TR/2012/NOTE-streamproc-20120531/
20:13:47 <timeless> marcosc: we can put OBSOLETE in the background
20:13:50 <timeless> Josh_Soref: it doesn't work
20:13:55 <timeless> dsr: if we move it to a NOTE
20:14:03 <timeless> ... we need to publish the new specs (FPWD)
20:14:29 <timeless> mounir: there are many things to fix
20:14:33 <timeless> ... we don't have a replacement yet
20:14:39 <timeless> ... saying we're going to remove that document
20:14:44 <timeless> ... it's ust moving the problem
20:14:59 <timeless> s/ust/just/
20:15:13 <timeless> ... if we say we have new documents and they have the same immature documents
20:15:16 <timeless> ... it doesn't fix anything
20:15:26 <timeless> ... the document is immature because no one is interested and it's too big
20:15:43 <timeless> ... we have people interested in implementing, but no one willing to give feedback
20:15:54 <timeless> ... the spec will become like DAP specs
20:16:10 <timeless> ... Vibration and Battery
20:16:19 <timeless> ... mozilla pushed for something in Battery, people had comments
20:16:27 <timeless> ... we fixed them, but no one challenged our vision
20:16:31 <timeless> ... and that's unfortunate
20:16:34 <timeless> ... that's what we're looking for
20:17:03 <timeless> anssik: the issue is that people outside this room are unclear of the status
20:17:09 <timeless> ... not letting them know the status isn't helping
20:17:14 <timeless> ... we're not aware of implementations
20:17:20 <timeless> ... and it hasn't been reviewed by implementers
20:17:25 <timeless> ... we're looking for implementers
20:17:31 <timeless> ... i'm looking for things
20:17:37 <timeless> ... people who know will find ED
20:17:44 <timeless> ... but people who use google will find TR
20:18:00 <timeless> dsr: if we're looking for implementation experience, then we should update the TR
20:18:19 <timeless> mounir: i'm open to updating TR status saying it's a draft, and it's not ready to be implemented
20:18:24 <timeless> ... but FPWD means that
20:18:59 <timeless> mounir: anyone else w/ comments on the runtime spec?
20:18:59 <room> q?
20:19:01 <timeless> [ Silence ]
20:19:09 <opoto> q+
20:19:20 <timeless> ack opoto
20:19:28 <timeless> opoto: generic question
20:19:34 <timeless> ... on specific details, but general approach
20:19:39 <timeless> ... about installed applications
20:19:42 <timeless> ... we raised it on github
20:19:53 <timeless> ... #108
20:19:59 <room> https://github.com/sysapps/runtime/issues/108
20:20:15 <timeless> s|https://github.com/sysapps/runtime/issues/108|-> https://github.com/sysapps/runtime/issues/108 Executing installed System Applications in browser|
20:20:21 <timeless> opoto: the specification isn't clear
20:20:28 <timeless> ... and i think we should all have the same understanding
20:20:40 <timeless> ... there was a response from jmajnert
20:20:46 <timeless> ... want to know about the room's opinion
20:21:23 <timeless> ... is it in the same runtime?
20:21:28 <chaals1> rrsagent, draft minutes
20:21:28 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/28-sysapps-minutes.html chaals1
20:21:44 <timeless> ... my understanding is that it should be able to run it in the same browser session
20:22:11 <timeless> ... a web page could redirect to an installed app
20:22:21 <timeless> ... or an installed app could redirect to the originating application
20:22:32 <timeless> ... or allow an installed app running w/in an iframe
20:22:54 <wonsuk1> q?
20:24:19 <timeless> Josh_Soref: speaking from the Web Intents TF
20:24:30 <timeless> ... we pushed out on iframe to later because it was scary
20:24:46 <timeless> ... it's incredibly valuable to be able to attack privileged apps
20:24:54 <timeless> mounir: each App has its own Cookie Jar
20:25:06 <timeless> ... the Browser and the NYT app have different Jars
20:25:20 <timeless> ... after this, i'm looking for people to come w/ experience
20:25:40 <timeless> ... i think a nice web model would be, if you install the NYT app, and you go to NYT, they'd share state
20:26:00 <timeless> q+ to talk about NYT+Twitter+@SEA
20:26:07 <timeless> q- timeless
20:26:10 <timeless> q+ Josh_Soref to talk about NYT+Twitter+@SEA
20:27:21 <timeless> [ Josh_Soref delivers a news flash about NYTimes.com and Twitter having their DNS hacked ]
20:27:49 <timeless> [ which results in scary propositions in case you had an installed app which was interested in trusting the user ]
20:28:07 <timeless> marcosc: it annoyed users in Opera to install an app having already been logged in
20:28:11 <timeless> ... having to log in again
20:31:23 <wonsuk1> q?
20:31:28 <timeless> ack Josh_Soref
20:31:28 <Zakim> Josh_Soref, you wanted to talk about NYT+Twitter+@SEA
20:32:44 <timeless> mounir: i can add a note saying that this is looking for feedback
20:32:54 <timeless> ... we can work on event pages and packaged apps
20:33:00 <timeless> ... hopefully we can move forward on them
20:33:33 <timeless> ... App Manifest v. Packaged App Manifest
20:33:44 <timeless> marcosc: origin: field
20:33:46 <timeless> ... permissioning
20:33:47 <timeless> ... stuff
20:34:35 <timeless> marcosc: ok, a larger packaged apps spec might be ok
20:34:38 <timeless> ... um. ok.
20:35:06 <timeless> Topic: Agenda
20:35:12 <timeless> mounir: tomorrow morning is device capabilities
20:35:15 <timeless> ... nothing else
20:35:45 <timeless> ... we can discuss device capabilities, but it'll be quick
20:35:53 <timeless> ... but the rest is ....
20:36:02 <timeless> ... do we want to move the TF to tomorrow morning?
20:36:50 <timeless> anssik: we could work on life cycle and nail down issues
20:36:59 <timeless> mounir: we could try to work on event pages
20:37:03 <timeless> ... try to work on datastore
20:37:07 <timeless> ... try to work on socket api
20:37:15 <timeless> ... are people interested, except the four of us?
20:37:24 <timeless> Claes: is anyone more than me interested in talking socket api?
20:37:27 <timeless> marcosc: i'm interested
20:37:40 <timeless> mounir: we can't talk about all things at the same time
20:38:02 <timeless> ... but, marcosc, you can't be in multiple places at once, right?
20:38:57 <timeless> mounir: who here for Socket API?
20:38:59 <timeless> ... 4
20:39:12 <timeless> ... Datastore
20:39:13 <timeless> ... 4
20:39:35 <timeless> ... Event Pages
20:39:39 <timeless> ... [most of the room]
20:40:00 <timeless> ... we could have a group for datastore+telephony
20:40:07 <timeless> zkis: i think they're quite different
20:40:21 <timeless> marcosc: what are we doing in the afternoon?
20:40:55 <timeless> zkis: i think datastore could be an hour
20:40:58 <timeless> ... sockets, an hour
20:41:03 <timeless> ... event pages may take more than an hour
20:41:07 <timeless> mounir: a long time
20:41:15 <timeless> zkis: telephony
20:41:21 <timeless> mounir: maybe two sessions
20:41:25 <timeless> marcosc: maybe three
20:41:28 <timeless> ... you can do it
20:42:39 <timeless> mounir: we could start with Socket / Event Pages
20:42:45 <timeless> ... Datastore / Event Pages
20:43:07 <timeless> zkis: but, mounir, you need to be in both
20:43:11 <timeless> mounir: i can't split in two
20:43:21 <timeless> spoussa: i support your proposal
20:43:35 <timeless> zkis: socket/telephony is different people
20:43:46 <anssik> +1 on the suggested TF split
20:43:51 <timeless> ... sequentially Datastore+
20:44:01 <timeless> mounir: i'm open to a Telephony session
20:44:07 <timeless> marcosc: how much time do we need in the afternoon
20:44:14 <timeless> mounir: i'd like to keep time there
20:44:26 <timeless> marcosc: dev outreach
20:44:29 <timeless> [ hand waving ]
20:44:31 <timeless> [ laughter ]
20:44:56 <timeless> mounir: i was expecting feedback on the agenda in advance
20:58:10 <sicking> sicking has joined #sysapps
21:01:02 <timeless> marcosc: I made something
21:01:07 <timeless> [ Applause ]
21:01:23 <timeless> marcosc: for things you want to attend, put your names on stickies
21:01:29 <timeless> ... when you've done that, you're free to go
21:11:35 <Zakim> -[Mozilla]
21:11:36 <Zakim> UW_SYSAPPS()8:00AM has ended
21:11:36 <Zakim> Attendees were [Mozilla], sicking
21:12:39 <marcosc> marcosc has joined #sysapps
21:20:18 <timeless> RRSAgent, draft minutes
21:20:18 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/28-sysapps-minutes.html timeless
21:20:27 <timeless> [ Adjourned ]
21:20:36 <timeless> RRSAgent, draft minutes
21:20:36 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/28-sysapps-minutes.html timeless
21:20:45 <timeless> Zakim, bye
21:20:45 <Zakim> Zakim has left #sysapps
21:20:49 <timeless> RRSAgent, bye
21:20:49 <RRSAgent> I see no action items