07:33:05 RRSAgent has joined #sysapps 07:33:06 logging to http://www.w3.org/2013/04/10-sysapps-irc 07:33:10 rrsagent, draft minutes 07:33:10 I have made the request to generate http://www.w3.org/2013/04/10-sysapps-minutes.html JonathanJ1 07:33:12 s/MM:/ML:/ 07:33:20 TOPIC: Alarm API 07:33:36 Present+ Jonathan_Jeon 07:33:46 Present+ Mounir_Lamouri 07:34:26 Present+ Wonsuk_Lee 07:34:35 Claes has joined #sysapps 07:34:53 http://web-alarms.sysapps.org/ 07:35:22 ...CD describes the alarm api... 07:35:46 q+ timeless 07:36:02 Zakim has joined #sysapps 07:36:11 q+ timeless 07:36:41 chaals has joined #sysapps 07:36:42 CD describes the AlarmInterface... 07:36:53 ZK: can the alarm fire once or many times? 07:36:56 CD: only once 07:37:40 CD: we already have some inconsistency, some specs use IDs others use objects 07:38:28 q+ to ask about repetitive alarms, e.g. daily, weekly, weekday, weekends, etc. with use cases such as downloading news, horoscopes etc. 07:38:32 CD: if you only have the ID, because the UA/backend can't reconstruct the object, then you can only use the ID 07:40:05 ML: when we designed the messaging API, we made it possible to use both the object or the ID 07:40:16 Re: remove(alarmID). clearWatch in Geolocation and MediaStream Tracks refer to ID's. I think this method in Alarm API is OK as spec'ed currently. 07:40:45 ZK: I think it would be correct to use the ID, but you can also use the object. 07:41:11 AK: if you have the id stored in, say, localStorage, you can still use the ID 07:41:34 CD: the proposal is support both the object or the ID 07:42:14 q+ to make sure the specs specify it's not only to create alarm clocks apps 07:42:20 JC: I can just wrap the API to extract the ID from an object, but the ID is what matters 07:42:57 ...question about AlarmRequest... 07:43:08 q? 07:43:12 q+ 07:43:20 s/...question about/Gene: why do we use AlarmRequest instead of DOMRequest?/ 07:43:35 CD: we didn't have DOMRequest at the time the spec was written, and now we have DOMFuture 07:43:55 ack timeless 07:43:58 Milan_Patel has joined #sysapps 07:44:51 JS: In your intro, you made a comment about "restart". I was looking for the word "restart" in the spec. The spec does not make it clear how the alarms are restored or if they have to be restored. 07:45:20 genelian has joined #sysapps 07:45:22 ML: The alarm API does not define how the alarms are reconstructed because it's dependent on system messages 07:45:48 CD: I defer that to system messages in the spec 07:46:31 JC: but if the alarm goes off when the device is off, you need to say that when the device is on, that alarm should still fire, even if it's the past. That kind of behavior should be in the spec. 07:46:41 JC: it should be normative 07:46:44 q? 07:46:49 q+ 07:47:06 ack dsr 07:47:06 dsr, you wanted to ask about repetitive alarms, e.g. daily, weekly, weekday, weekends, etc. with use cases such as downloading news, horoscopes etc. 07:47:11 AK: with a bit of rewording, this is easy to fix 07:47:49 DR: I was thinking about reoccurring alarm, like "every week". Is this something in scope? 07:48:13 ML: We thought about adding that to FxOS... but it's complicated to do. 07:48:24 CD: it's currently not in the spec 07:49:01 CD: the calendar should be able to handle that use case 07:49:25 AK: "The Alarm API supports the following features" list in the Introduction section should be a list of requirements, use RFC terms 07:49:38 s/complicated to do./complicated to do and would be used by a very tiny set of applications./ 07:49:48 q? 07:49:53 ack mounir 07:49:53 mounir, you wanted to make sure the specs specify it's not only to create alarm clocks apps 07:50:02 q- 07:50:36 ML: When I wrote spec it was not very obvious that it supposed to open an application. We could change the name. 07:50:48 Josh: We have a lot of people that would support that 07:51:20 s/When I wrote/When I read/ 07:51:23 Josh: there is lots of things in linux and in windows that you can look for inspiration for a new name 07:51:30 q? 07:51:45 ack Marcosc 07:55:34 MC: we should improve the definition |data| in add(), we could use something like a Dictionary 07:55:45 q+ 07:55:49 CD: we could maybe use structured clone? 07:56:32 MC: I don't like them, what is using them? 07:56:40 gmandyam: Blobs 07:56:46 CD: Web Messaging 07:57:53 q? 07:58:33 q+ to ask if notes are taken regarding the issues that have to be solved 07:58:59 ack anssik 07:59:01 ack anssik 07:59:31 AK: what are the use cases for the data 07:59:31 ? 08:00:30 q+ 08:00:33 AK: they could serialise images, etc. into text. We might need to define what happens if you exceed a size limit. 08:00:53 ML: We will need to define something there so it fails and the developer is notified. 08:01:23 Josh: question is, what is the largest date you can image, and then set a reasonable limit. 08:02:16 s/date/data/ 08:02:19 s/image/imagine/ 08:03:17 See http://lists.w3.org/Archives/Public/public-sysapps/2013Jan/0082.html for Jonas's explanation on the data argument for Alarm API. 08:03:27 kenneth_ has joined #sysapps 08:03:39 sunghan has joined #sysapps 08:03:49 CD: how does IndexDB handle exceeding quota? 08:04:02 MC: I don't know, probably throws an exception 08:04:07 MC: need to check 08:04:07 dsuwirya has joined #sysapps 08:04:31 CD: one method that is in contacts is clear(), but it's not in this API 08:04:39 ML: we could add that 08:04:48 q? 08:04:55 ack mounir 08:04:55 mounir, you wanted to ask if notes are taken regarding the issues that have to be solved 08:05:52 RESOLUTION: add a clear() method. 08:06:01 https://github.com/sysapps/web-alarms/issues/1 08:06:11 AK: we may want to add a new step to the add() algorithm, something like: "If the data exceeds an implementation-dependent limit, then [...]" 08:06:36 https://github.com/sysapps/web-alarms/issues/2 08:07:37 https://github.com/sysapps/web-alarms/issues/3 08:07:47 q+ to talk more about persistent data 08:08:03 q? 08:08:13 https://github.com/sysapps/web-alarms/issues/4 08:08:38 ack gmandyam 08:10:57 GM: I dropped the link into IRC for Jonas' comments about this 08:13:17 q+ 08:14:18 https://github.com/sysapps/web-alarms/issues/5 08:14:34 MC: we need to bikeshed the name 08:15:01 ... bikeshedding ensues... 08:15:06 job scheduler 08:15:06 q? 08:15:08 https://github.com/sysapps/web-alarms/issues/6 08:15:16 ack lgombos 08:15:16 lgombos, you wanted to talk more about persistent data 08:16:13 LG: do we need to add some text with about the data argument. What happens to that data when the app is uninstalled? 08:16:39 s/job/web/ 08:17:13 q? 08:17:16 ML: we should add to the spec that when the app is uninstalled the alarms for this app should be cleared. We need to file an issue for this. 08:17:21 q- 08:17:48 ack anssik 08:18:07 CD: the runtime spec also speaks about clearing data 08:18:46 q+ 08:19:19 Gene: should we return a cursor instead of an array in getPending()? 08:20:03 ML: there has been a concept of a progress future that is useful for steaming data 08:20:15 ML: we don't need to use that now, but something to keep in mind 08:20:16 q+ 08:20:28 q? 08:20:34 ack gmandyam 08:20:36 ack gmandyam 08:21:20 GM: when you talk about persisting alarm data, is that the space that is allocated to the application? where is the data stored and how it that data secured? 08:21:32 Jungkee has joined #sysapps 08:21:42 Gene: we store them in a system database 08:22:13 Present+ Jungkee_Song 08:22:25 GM: then maybe it should be specified how it's stored 08:22:35 JC: Sounds like an implementation detail 08:22:43 q+ 08:22:43 MC: yes, I agree with JC 08:23:12 JC: there are multiple ways to implement this. 08:23:34 GM: but the data could persist? 08:23:50 JC: no, because the spec says to remove it - so that implementation would not conform to the spec. 08:24:55 q+ 08:24:56 ... discussion continues about how data is persisted for an app ... 08:25:36 rrsagent, make minutes 08:25:36 I have made the request to generate http://www.w3.org/2013/04/10-sysapps-minutes.html tomoyuki 08:26:42 q+ 08:27:08 GM: I'm asking that we make sure we say that the alarm data is associated with the application data 08:27:22 q? 08:28:33 ML: there is examples of timezones in the spec? Or did I miss those? 08:28:38 ack 08:28:40 ack me 08:28:42 MC: They are at the bottom of the spec 08:28:42 ack thinker 08:28:45 IMO implementations should be able to make the choice on where and how to store alarm data 08:28:57 q- 08:29:51 thinker: : maybe we only need one alarm per application? 08:30:32 I'd disagree 08:30:32 q? 08:30:43 gene: we can set multiple alarms and they will be queued 08:31:53 (...discussion about timezones....) 08:32:17 DKA has joined #sysapps 08:32:49 Present+ Dan Appelquist 08:33:31 rrsagent, draft minutes 08:33:31 I have made the request to generate http://www.w3.org/2013/04/10-sysapps-minutes.html JonathanJ1 08:34:01 q? 08:34:03 Present+ Sakari_Poussa 08:34:44 q? 08:35:00 Present+ Eduardo_Fullea 08:35:03 sicking has joined #sysapps 08:35:10 rrsagent, make logs public 08:36:58 Present+ Zoltan_Kis 08:37:22 the reason that having multiple alarms per app helps is that otherwise applications will have to do global coordination between *all* subsystems within the app in order to figure out which alarm is the next one that should be scheduled. This makes it harder to have a library, like a jQuery plugin, which uses the alarm API. People would have to come up with pseudo standards for APIs that they can use to coordinate the scheduling of alarms. 08:51:33 s/the reason/sicking: the reason/ 08:51:34 q? 08:52:13 q? 08:52:16 JonathanJ1 has joined #sysapps 08:52:18 scribe: timeless 08:52:31 ack genelian 08:53:34 genelian: it's strange to have `respectTimezone` attribute and argument 08:53:43 [ it's confusing ? ] 08:53:49 genelian: and the attributes should be readonly 08:53:51 q? 08:54:11 q? 08:54:36 Josh_Soref: does getAll() define an order 08:55:24 Marcosc: it would be nice to return it in order 08:55:37 mounir: i agree 08:55:50 gmandyam: you have the creation order, or firing order 08:56:22 Marcosc: the temporal order is more useful 08:56:36 sicking: you could take time zones first or second 08:56:49 chris: should we split the function? 08:57:00 mounir: the issue should be to define an order 08:57:07 mounir: it would be nice to have one 08:57:15 https://github.com/sysapps/web-alarms/issues/11 08:57:28 mounir: the specification has a file bug link, it doesn't point to the right place 08:57:58 q? 08:59:05 Josh_Soref: what happens if the system time moves? 08:59:29 mounir: it should behave the same way as if the system was off 08:59:38 ... firing when available 09:00:23 https://github.com/sysapps/web-alarms/issues/13 09:00:36 hsinyi has joined #sysapps 09:01:20 Josh_Soref: is there a defined order for firing a bunch of alarms if the system was off/unavailable for the set of alarms 09:01:32 mounir: it isn't defined, but it should be, in the time order 09:01:47 gmandyam: we went over the DST section for skipping alarms 09:01:51 ... i wanted it in non-normative 09:02:05 ... i think you should put it in examples 09:02:09 chris: the sequence is important 09:02:14 ... for the app developers 09:02:26 gmandyam: how is this different from the DST example? 09:02:50 gmandyam: If you have a clock-advance (discussed in email) 09:02:57 ... it could potentially skip over an alarm 09:03:05 ... we concluded that the alarm immediately fires 09:03:33 ... if you have an alarm firing at 12:01 post daylight savings 09:03:43 chris: what's not addressed is the example only sets ONE alarm 09:03:52 mounir: two issues, one is similar to time-change forward 09:03:57 ... the second is multiple-alarms 09:04:03 ... we need to fire them in a specific order 09:04:14 DKA has joined #sysapps 09:04:23 ... if we don't have normative text, the implementation might never fire the alarm 09:04:25 q? 09:04:56 Topic: Data Model and Filtering 09:05:03 sicking: i don't think we have any slides 09:05:22 eduardo: a good starting point is the Messaging API 09:05:34 ... we had two different options in the draft 09:05:38 ... maybe we can look at them 09:05:59 ... should i go through filtering in the messaging api? 09:06:58 http://messaging.sysapps.org/#messagingfilter-interface 09:07:07 http://messaging.sysapps.org/#idl-def-MessagingFilter 09:07:37 eduardo: we have two approaches in this draft 09:07:47 ... the first is specific to the needs of the Messaging API 09:08:06 ... we have attributes (start date, end date, sender, service id, read) 09:08:22 ... with this filter, we can cope with the most usual UCs for Messaging 09:08:30 sicking: can you go to the Messaging Interface? 09:09:05 http://messaging.sysapps.org/#idl-def-Message 09:09:44 sicking: my point is that 09:09:44 http://messaging.sysapps.org/#idl-def-Messaging 09:09:49 ... this general pattern has two problems 09:10:00 ... A. too complicated to implement, that they're not implementable 09:10:08 ... B. they aren't enough to implement the UC 09:10:35 q+ 09:10:57 ... the problem we ran into when we did FirefoxOS 09:11:03 ... we started with just FindMessages() 09:11:08 ... all messages that match a filter 09:11:13 ... the first thing we did when we did a UI 09:11:19 ... was we needed a conversation overview 09:11:30 ... it isn't a thing you can do w/ a filtering API 09:11:39 ... the Message Overview isn't a simple 09:11:46 ... "give me all messages that match a criteria" 09:11:56 ... it's "give me the first message that's unique given a criteria" 09:12:05 ... in this case "first unique given sender-receiver" 09:12:14 q+ 09:12:16 ... then we had message threads - you call it find Conversations 09:12:27 ... you're enabling a particular transform of the data 09:12:35 ... i don't actually want to filter, i want to do a grouping 09:12:44 ... but grouping criteria can be very complicated 09:12:45 kenneth_ has joined #sysapps 09:12:55 ... what we do in FirefoxOS is very complicated 09:13:02 ... deciding if two numbers match 09:13:10 ... different countries aren't consistent about numbers 09:13:26 ... you have to do fuzzy application specific logic to decide whether to group messages 09:13:35 ... we call into a complicated JS function 09:13:42 ... and then we call into it 09:13:48 ... and store the first 10 groupings 09:13:57 ... which is what you see when you first open 09:14:06 ... for each of these 10, you want to see a name, 09:14:15 ... "do i have any unread messages w/ this person" 09:14:23 ... other UI would show "do i have unread drafts w/ this person" 09:14:28 ... others might want a count 09:14:34 ... and the last message sent/received 09:14:40 ... this is a pretty advanced data transofrm 09:14:47 s/transofrm/transform/ 09:14:50 zkis: it supports it 09:14:56 sicking: does it support getting the count 09:15:01 ... in addition to do i have drafts? 09:15:06 zkis: your point is valid 09:15:11 ... what is the ideal messaging api? 09:15:23 sicking: the other problem is you need to get this information very fast 09:15:30 ... it isn't acceptable to go over the whole database 09:15:36 ... you can't scan 10,000 entries 09:15:41 ... you need a precomputed index 09:15:48 ... the only way this is reasonably doable 09:15:55 ... is by letting application logic provide this index 09:15:57 +1 09:15:58 q- 09:16:09 ... there are sooo many application specific bits 09:16:13 +1 09:16:26 ... in SMS sending, there could be 10 messages sent for one message "sent to 10 people" 09:16:42 zkis: do you mean messages can belong to multiple conversations? 09:16:46 sicking: sure 09:16:51 ... even the iPhone couldn't handle this 09:16:57 ... you need pretty advanced heuristics 09:17:08 ... "when was the last time i sent a message to this person" 09:17:19 ... there's no way to do all of this in the API 09:17:29 zkis: you're saying that you need precomputed data 09:17:34 ... and you need a way to get an id 09:17:52 ... and you need a way to get messages by conversation id 09:18:06 ... you set the conversation id 09:18:24 q+ 09:18:37 q+ 09:18:37 ack zkis 09:18:39 ack zkis 09:18:43 ack mounir 09:18:57 mounir: your [zkis] idea of having the app define conversation 09:18:59 ... doesn't scale 09:19:10 ... the SMS app needs the last message, and the number of messages 09:19:10 q+ 09:19:16 ... because it needs to see things very fast 09:19:22 ... the database needs to be indexed based on that 09:19:25 ack me 09:19:33 zkis: the question is what do you need from the API to do this? 09:19:44 mounir: the API should not have all this 09:20:01 ... the API should have a way to notify for new messages 09:20:11 zkis: the api ... 09:20:15 [ scribe failing ] 09:20:19 q? 09:20:26 sicking: you have a problem w/ 2 sms applications installed 09:20:33 ... that disagree on how they thread 09:20:42 ... they'd stomp on eachother 09:20:50 zkis: this is an implementation issue 09:21:02 ... do you have unique conversation ids across multiple applications? 09:21:04 q+ 09:21:11 sicking: if i write that a conversation id for a message is 1 09:21:26 zkis: the implementation of the api should generate the conversation id 09:21:38 sicking: that means that an app can't choose how to do threading 09:21:44 zkis: i don't understand 09:21:54 sicking: it's a ui decision about how to do grouping 09:22:09 ... is it the API or the App that assigns a conversation id 09:22:24 ack sicking 09:22:29 q? 09:22:50 zkis: the application can call an api to assign a message to a conversation (the id came from the api) 09:22:53 q+ 09:23:09 eduardo: to elaborate on how findConversations work 09:23:12 ... we have groupBy 09:23:25 ... we decided there were two main ways to group messages into conversations 09:23:32 ... one was to group by recipient 09:23:37 ... the other was to group by subject 09:23:52 ... that's more for email, which isn't in the scope for this api 09:24:02 ... conversation by recipient or conversation by subject 09:24:22 ... the application invokes findConversations() based on recipient 09:24:27 ... the api returns a cursor 09:24:35 ... and the application can draw the UI 09:24:50 ... and the application can access a message from a thread 09:24:54 ack gmandyam 09:24:59 sicking: can you change the conversation for which a message belongs? 09:25:18 gmandyam: we had a case where an end user sent an sms message to a server 09:25:23 ... two support requests came in 09:25:40 ... and it was impossible to string together the messages 09:26:05 ... i think subject grouping isn't possible outside MMS 09:26:15 q+ 09:26:15 ... i think the only thing you can do is group by recipients 09:26:22 ... you can't tell what they're responding to 09:26:30 ... you can have two threads that are started 09:26:36 sicking: we're offtopic 09:26:51 sicking: i haven't gotten to my problem 09:26:58 joseCantera: i'd like to know your proposal 09:27:07 +q 09:27:10 q+ 09:27:14 sicking: there's a lot in this API that severely constrains the types of UI an app can produce 09:27:17 s/+q/q+/ 09:27:43 sicking: how do i, in a performant way, implement a ui my way 09:27:49 zkis: you do it your way 09:28:12 Zakim, clear the queue 09:28:12 I don't understand 'clear the queue', timeless 09:28:18 q= 09:28:30 queue=eduardo, sicking, zkis, Marcosc 09:28:58 sicking: how do i when i launch and haven't yet seen a lot of new SMS messages 09:29:01 ... build a UI 09:29:13 ... i want an API that allows me to use indexedDB or whatever 09:29:22 ... it has a store of messages in the system 09:29:28 ... and whenever messages are added/removed 09:29:31 ... i'm told about them 09:29:47 ... so whenever i'm run, i can do this 09:30:01 zkis: so you want a sync interface 09:30:12 [ scribe isn't sure if Sync means "synchronous" or "synchronize" ] 09:30:22 sicking: you made a bunch of UI decisions when you made this api 09:30:29 ... and if i don't agree, then it's useless to me 09:30:38 ... and if there's only one SMS app 09:30:50 ... then there's a lot of implementation code and no consumers 09:30:56 sicking: if i send a message to 10 friends 09:31:06 ... if one replies, i want to group the reply into this conversaion 09:31:13 s/conversaion/conversation/ 09:31:25 gmandyam: how do you draw the association without a subject line 09:31:33 ... it's application specific 09:31:38 sicking: yes, it's application specific 09:31:44 ... it's heuristics, it will fail sometimes 09:32:01 gmandyam: it's what i'm talking about w/ sending two questions to a support center and getting two responses 09:32:19 sicking: this api enforces a specific userinterface-message-threading model 09:32:32 ... the general design principle for web apis is to solve 80% of UCs 09:32:38 if we remove findConversations we will have a more simple API, which it is an advantage. Then, we would need a mechanism to snapshot data between the platform DB and the app DB 09:32:39 ... unless this does that, it's wrong 09:32:51 eduardo: your proposal is valid for some corner UCs 09:32:55 ... but it complicates most of the apps 09:32:59 zkis: i'd like to honor it 09:33:05 richt has joined #sysapps 09:33:10 ... let's try to make it that you don't have this junk 09:33:18 ... we still have your sync interface 09:33:29 sicking: "synchronize" 09:33:39 ... i'm proposing a Synchronize api 09:33:49 ... it makes life more difficult for application authors 09:33:59 ... we write a library that implements threading 09:34:09 ... and let people use that if they like 09:34:25 sicking: the basic rule of thumb is that filtering function performance 09:34:35 ... needs to be roughly proportional to the number of messages you return 09:35:09 ... it shouldn't need to do a full/partial table scan to get the messages you want 09:35:20