SV_MEETING_TITLE -- 10 Apr 2013

<Marcosc> s/MM:/ML:/

Alarm API

<JonathanJ1> http://web-alarms.sysapps.org/

<Marcosc> ...CD describes the alarm api...

<Marcosc> CD describes the AlarmInterface...

<Marcosc> ZK: can the alarm fire once or many times?

<Marcosc> CD: only once

<Marcosc> CD: we already have some inconsistency, some specs use IDs others use objects

<Marcosc> CD: if you only have the ID, because the UA/backend can't reconstruct the object, then you can only use the ID

<Marcosc> ML: when we designed the messaging API, we made it possible to use both the object or the ID

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

<Marcosc> ZK: I think it would be correct to use the ID, but you can also use the object.

<Marcosc> AK: if you have the id stored in, say, localStorage, you can still use the ID

<Marcosc> CD: the proposal is support both the object or the ID

<Marcosc> JC: I can just wrap the API to extract the ID from an object, but the ID is what matters

<Marcosc> Gene: why do we use AlarmRequest instead of DOMRequest? AlarmRequest...

<Marcosc> CD: we didn't have DOMRequest at the time the spec was written, and now we have DOMFuture

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

<Marcosc> ML: The alarm API does not define how the alarms are reconstructed because it's dependent on system messages

<Marcosc> CD: I defer that to system messages in the spec

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

<Marcosc> JC: it should be normative

<Zakim> dsr, you wanted to ask about repetitive alarms, e.g. daily, weekly, weekday, weekends, etc. with use cases such as downloading news, horoscopes etc.

<Marcosc> AK: with a bit of rewording, this is easy to fix

<Marcosc> DR: I was thinking about reoccurring alarm, like "every week". Is this something in scope?

<Marcosc> ML: We thought about adding that to FxOS... but it's complicated to do and would be used by a very tiny set of applications.

<Marcosc> CD: it's currently not in the spec

<Marcosc> CD: the calendar should be able to handle that use case

<anssik> AK: "The Alarm API supports the following features" list in the Introduction section should be a list of requirements, use RFC terms

<Zakim> mounir, you wanted to make sure the specs specify it's not only to create alarm clocks apps

<Marcosc> ML: When I read spec it was not very obvious that it supposed to open an application. We could change the name.

<Marcosc> Josh: We have a lot of people that would support that

<Marcosc> Josh: there is lots of things in linux and in windows that you can look for inspiration for a new name

<mounir> MC: we should improve the definition |data| in add(), we could use something like a Dictionary

<mounir> CD: we could maybe use structured clone?

<mounir> MC: I don't like them, what is using them?

<mounir> gmandyam: Blobs

<mounir> CD: Web Messaging

<Marcosc> AK: what are the use cases for the data

<Marcosc> ?

<Marcosc> AK: they could serialise images, etc. into text. We might need to define what happens if you exceed a size limit.

<Marcosc> ML: We will need to define something there so it fails and the developer is notified.

<Marcosc> Josh: question is, what is the largest data you can imagine, and then set a reasonable limit.

<gmandyam> See http://lists.w3.org/Archives/Public/public-sysapps/2013Jan/0082.html for Jonas's explanation on the data argument for Alarm API.

<Marcosc> CD: how does IndexDB handle exceeding quota?

<Marcosc> MC: I don't know, probably throws an exception

<Marcosc> MC: need to check

<Marcosc> CD: one method that is in contacts is clear(), but it's not in this API

<Marcosc> ML: we could add that

<Zakim> mounir, you wanted to ask if notes are taken regarding the issues that have to be solved

<Marcosc> RESOLUTION: add a clear() method.

<chris> https://github.com/sysapps/web-alarms/issues/1

<anssik> AK: we may want to add a new step to the add() algorithm, something like: "If the data exceeds an implementation-dependent limit, then [...]"

<chris> https://github.com/sysapps/web-alarms/issues/2

<chris> https://github.com/sysapps/web-alarms/issues/3

<chris> https://github.com/sysapps/web-alarms/issues/4

<Marcosc> GM: I dropped the link into IRC for Jonas' comments about this

<chris> https://github.com/sysapps/web-alarms/issues/5

<Marcosc> MC: we need to bikeshed the name

<Marcosc> ... bikeshedding ensues...

<anssik> web scheduler

<chris> https://github.com/sysapps/web-alarms/issues/6

<Zakim> lgombos, you wanted to talk more about persistent data

<Marcosc> LG: do we need to add some text with about the data argument. What happens to that data when the app is uninstalled?

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

<Marcosc> CD: the runtime spec also speaks about clearing data

<mounir> Gene: should we return a cursor instead of an array in getPending()?

<Marcosc> ML: there has been a concept of a progress future that is useful for steaming data

<Marcosc> ML: we don't need to use that now, but something to keep in mind

<Marcosc> 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?

<Marcosc> Gene: we store them in a system database

<Marcosc> GM: then maybe it should be specified how it's stored

<Marcosc> JC: Sounds like an implementation detail

<Marcosc> MC: yes, I agree with JC

<Marcosc> JC: there are multiple ways to implement this.

<Marcosc> GM: but the data could persist?

<Marcosc> JC: no, because the spec says to remove it - so that implementation would not conform to the spec.

<Marcosc> ... discussion continues about how data is persisted for an app ...

<Marcosc> GM: I'm asking that we make sure we say that the alarm data is associated with the application data

<Marcosc> ML: there is examples of timezones in the spec? Or did I miss those?

<mounir> ack

<Marcosc> MC: They are at the bottom of the spec

<zkis> IMO implementations should be able to make the choice on where and how to store alarm data

<Marcosc> thinker: : maybe we only need one alarm per application?

<zkis> I'd disagree

<Marcosc> gene: we can set multiple alarms and they will be queued

<Marcosc> (...discussion about timezones....)

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

<scribe> scribe: timeless

genelian: it's strange to have `respectTimezone` attribute and argument

[ it's confusing ? ]

genelian: and the attributes should be readonly

Josh_Soref: does getAll() define an order

Marcosc: it would be nice to return it in order

mounir: i agree

gmandyam: you have the creation order, or firing order

Marcosc: the temporal order is more useful

sicking: you could take time zones first or second

chris: should we split the function?

mounir: the issue should be to define an order
... it would be nice to have one

<chris> https://github.com/sysapps/web-alarms/issues/11

mounir: the specification has a file bug link, it doesn't point to the right place

Josh_Soref: what happens if the system time moves?

mounir: it should behave the same way as if the system was off
... firing when available

<chris> https://github.com/sysapps/web-alarms/issues/13

Josh_Soref: is there a defined order for firing a bunch of alarms if the system was off/unavailable for the set of alarms

mounir: it isn't defined, but it should be, in the time order

gmandyam: we went over the DST section for skipping alarms
... i wanted it in non-normative
... i think you should put it in examples

chris: the sequence is important
... for the app developers

gmandyam: how is this different from the DST example?
... If you have a clock-advance (discussed in email)
... it could potentially skip over an alarm
... we concluded that the alarm immediately fires
... if you have an alarm firing at 12:01 post daylight savings

chris: what's not addressed is the example only sets ONE alarm

mounir: two issues, one is similar to time-change forward
... the second is multiple-alarms
... we need to fire them in a specific order
... if we don't have normative text, the implementation might never fire the alarm

Data Model and Filtering

sicking: i don't think we have any slides

eduardo: a good starting point is the Messaging API
... we had two different options in the draft
... maybe we can look at them
... should i go through filtering in the messaging api?

<zkis> http://messaging.sysapps.org/#messagingfilter-interface

<eduardo> http://messaging.sysapps.org/#idl-def-MessagingFilter

eduardo: we have two approaches in this draft
... the first is specific to the needs of the Messaging API
... we have attributes (start date, end date, sender, service id, read)
... with this filter, we can cope with the most usual UCs for Messaging

sicking: can you go to the Messaging Interface?

<eduardo> http://messaging.sysapps.org/#idl-def-Message

sicking: my point is that

<eduardo> http://messaging.sysapps.org/#idl-def-Messaging

sicking: this general pattern has two problems
... A. too complicated to implement, that they're not implementable
... B. they aren't enough to implement the UC
... the problem we ran into when we did FirefoxOS
... we started with just FindMessages()
... all messages that match a filter
... the first thing we did when we did a UI
... was we needed a conversation overview
... it isn't a thing you can do w/ a filtering API
... the Message Overview isn't a simple
... "give me all messages that match a criteria"
... it's "give me the first message that's unique given a criteria"
... in this case "first unique given sender-receiver"
... then we had message threads - you call it find Conversations
... you're enabling a particular transform of the data
... i don't actually want to filter, i want to do a grouping
... but grouping criteria can be very complicated
... what we do in FirefoxOS is very complicated
... deciding if two numbers match
... different countries aren't consistent about numbers
... you have to do fuzzy application specific logic to decide whether to group messages
... we call into a complicated JS function
... and then we call into it
... and store the first 10 groupings
... which is what you see when you first open
... for each of these 10, you want to see a name,
... "do i have any unread messages w/ this person"
... other UI would show "do i have unread drafts w/ this person"
... others might want a count
... and the last message sent/received
... this is a pretty advanced data transform

zkis: it supports it

sicking: does it support getting the count
... in addition to do i have drafts?

zkis: your point is valid
... what is the ideal messaging api?

sicking: the other problem is you need to get this information very fast
... it isn't acceptable to go over the whole database
... you can't scan 10,000 entries
... you need a precomputed index
... the only way this is reasonably doable
... is by letting application logic provide this index

<mounir> +1

sicking: there are sooo many application specific bits

<Marcosc> +1

sicking: in SMS sending, there could be 10 messages sent for one message "sent to 10 people"

zkis: do you mean messages can belong to multiple conversations?

sicking: sure
... even the iPhone couldn't handle this
... you need pretty advanced heuristics
... "when was the last time i sent a message to this person"
... there's no way to do all of this in the API

zkis: you're saying that you need precomputed data
... and you need a way to get an id
... and you need a way to get messages by conversation id
... you set the conversation id

mounir: your [zkis] idea of having the app define conversation
... doesn't scale
... the SMS app needs the last message, and the number of messages
... because it needs to see things very fast
... the database needs to be indexed based on that

zkis: the question is what do you need from the API to do this?

mounir: the API should not have all this
... the API should have a way to notify for new messages

zkis: the api ...

[ scribe failing ]

sicking: you have a problem w/ 2 sms applications installed
... that disagree on how they thread
... they'd stomp on eachother

zkis: this is an implementation issue
... do you have unique conversation ids across multiple applications?

sicking: if i write that a conversation id for a message is 1

zkis: the implementation of the api should generate the conversation id

sicking: that means that an app can't choose how to do threading

zkis: i don't understand

sicking: it's a ui decision about how to do grouping
... is it the API or the App that assigns a conversation id

zkis: the application can call an api to assign a message to a conversation (the id came from the api)

eduardo: to elaborate on how findConversations work
... we have groupBy
... we decided there were two main ways to group messages into conversations
... one was to group by recipient
... the other was to group by subject
... that's more for email, which isn't in the scope for this api
... conversation by recipient or conversation by subject
... the application invokes findConversations() based on recipient
... the api returns a cursor
... and the application can draw the UI
... and the application can access a message from a thread

sicking: can you change the conversation for which a message belongs?

gmandyam: we had a case where an end user sent an sms message to a server
... two support requests came in
... and it was impossible to string together the messages
... i think subject grouping isn't possible outside MMS
... i think the only thing you can do is group by recipients
... you can't tell what they're responding to
... you can have two threads that are started

sicking: we're offtopic
... i haven't gotten to my problem

joseCantera: i'd like to know your proposal

sicking: there's a lot in this API that severely constrains the types of UI an app can produce
... how do i, in a performant way, implement a ui my way

zkis: you do it your way

sicking: how do i when i launch and haven't yet seen a lot of new SMS messages
... build a UI
... i want an API that allows me to use indexedDB or whatever
... it has a store of messages in the system
... and whenever messages are added/removed
... i'm told about them
... so whenever i'm run, i can do this

zkis: so you want a sync interface

[ scribe isn't sure if Sync means "synchronous" or "synchronize" ]

sicking: you made a bunch of UI decisions when you made this api
... and if i don't agree, then it's useless to me
... and if there's only one SMS app
... then there's a lot of implementation code and no consumers
... if i send a message to 10 friends
... if one replies, i want to group the reply into this conversation

gmandyam: how do you draw the association without a subject line
... it's application specific

sicking: yes, it's application specific
... it's heuristics, it will fail sometimes

gmandyam: it's what i'm talking about w/ sending two questions to a support center and getting two responses

sicking: this api enforces a specific userinterface-message-threading model
... the general design principle for web apis is to solve 80% of UCs

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

sicking: unless this does that, it's wrong

eduardo: your proposal is valid for some corner UCs
... but it complicates most of the apps

zkis: i'd like to honor it
... let's try to make it that you don't have this junk
... we still have your sync interface

sicking: "synchronize"
... i'm proposing a Synchronize api
... it makes life more difficult for application authors
... we write a library that implements threading
... and let people use that if they like
... the basic rule of thumb is that filtering function performance
... needs to be roughly proportional to the number of messages you return
... it shouldn't need to do a full/partial table scan to get the messages you want

zkis: can you add that as a requirement to the wiki?

sicking: i think we should focus on a small set of filters
... for each filter, you need to actively keep an index
... we looked at the context of the api

zkis: in that case, you only implement a few
... and only document a few

sicking: the point is that
... if an implementation is 100-times slower than another implementation
... then the former isn't a valid implementation
... we need two conformant implementations
... and we need them to be preformant
... it's ok if they're slow if it's returning a lot of data

<gmandyam> Current draft mixes MessageCursor and MessagingCursor: is this a bug or intentional?

sicking: it isn't ok to be slow because it doesn't have the right indexes

mikko: where's the store?

zkis: there's a store in JS and a store in system

spoussa: can someone explain the synchronize api?

zkis: it gives the messages since you last synchronized

sicking: it gives adds, removes, and changed

zkis: we have this in Telephony
... ofono does this
... Messaging is more complex
... i want to solve more than just your UC
... should we restrict this interface to just having sending

sicking: the platform needs to store the store for when the SMS application is changed

zkis: can we maintain a generic mechanism that chris defined
... but in documentation we restrict which ones you have to implement

[ performantly? at all? ]

zkis: in Tizen, we have datamodels in native

sicking: what type of filtering?

zkis: the filtering mounir drafted earlier
... could be done
... but instead of ...
... we restrict which fields must be handled
... for compliance

sicking: repeating mounir 's question
... what are the UCs for filtering like this
... it's much more advanced than anything i've seen
... most UIs just show threads

Josh_Soref: does FirefoxOS have searching() ?

sicking: No

Josh_Soref: because BlackBerry certainly does
... and I believe Nokia did

sicking: and we need full text searching

anssik: i think users expect full text search

zkis: and it's supported
... you can do filter with contains on body

mounir: we have this supported in the backend
... but because it's slow, we don't offer the UI

sicking: anytime we wave "implementation detail"
... we have to prove it's implemtented

<JonathanJ1> FYI - http://bit.ly/10SxCNJ (It's a Messaging API implementation on HyWAI platform. unfortunately, it's just works on android OS)

zkis: how does the api prevent you from getting this

mikko: is performance subject to w3?

Josh_Soref: we have a "is it a toy",

sicking: with CSS, we have items that only non-browsers could support
... "in theory they could be implemented" but no one has

zkis: what do we do?
... i don't see that the api prevents you from doing a performant implementation

sicking: the burden of proof is to show that it's implementable

zkis: we don't need to change this now

sicking: if you think it's implementable

zkis: i'd like to do the api so it satisfies your UC well enough
... i'm ok with splitting it behind another object property

sicking: i'm fine with submitting a proposal about synchronize
... and i'm fine with submitting a performance requirement

zkis: i think it's reasonable to ...

sicking: certainly anything is implementable
... but if it's so hard to implement
... i think it'd be simpler if we had a simpler api

joseCantera: we could remove findConversations()
... we could try to implement findConversations() in a js library
... findConversations() is a can of worms

zkis: it was your proposal, if i remember right

sicking: we learned from our mistakes

zkis: this was our compromise

sicking: the most common way is to filter on date-range and recipients
... or recipients and number of results

Marcosc: sicking brought up an interesting
... prefix this discussion
... i haven't looked at this spec
... i don't know much about messaging/filtering issues
... i understand the performance issues
... you mentioned IndexedDB
... and all this is databasing
... why wasn't something like this built on top of IndexedDB
... to provide something simpler

sicking: that's what i'm essentially proposing
... we have a synchronize() api that lets you download into your application's indexed db

zkis: how do you do this with a data-model on native?

sicking: this is a problem we had when we did our initial implementation on top of android
... Android has an internal SMS store
... since we aren't Android, we couldn't change their model
... by using Synchronize and a simple filter
... we lower the requirements on a backend
... to implement this, you need a very complex backend

zkis: suppose you have a very powerful backend
... i want to avoid forcing us to duplicate into javascript

sicking: this api requires a dramatically complicated thing
... whereas if we move this to js
... all that's needed on the device are those that are actually needed by the device
... yes you're duplicating some of the native logic
... but
... the upshot is that you need dramatically less
... i'm sure no one has an implementation that handles this performantly
... you don't have dynamic index generation
... if you're built on sqlite, you don't have dynamic index generation

zkis: what if we have it in the native side

sicking: in my mind, that's hypothetical

zkis: i need to make it work
... the UC is you might have a native app that handles messaging
... and you might deploy a JS app that wants to use the native side's data model

spoussa: if we remove findConversations() and some filtering
... you could still use the native database

zkis: i want apps to be compatible

chris: you want to reuse apps?

mikko: is the proposal to add synchronize() and see if things work

mounir: i don't understand why this makes your implementation to not work

zkis: it forces us to duplicate the logic and databases across between the native SMS app and the JS SMS app

sicking: this doesn't support fast searching

spoussa: you're assuming the api is slow

mikko: you specify your native app as non removable

anssik: i'm hearing a rough consensus that we want
... can we agree on a subset that is acceptable for all of us
... we have a pattern of pushing other bits to v2

zkis: one clean way out is to not deal w/ ...

anssik: you can use a library (which may not be performant)

spoussa: the library can implement

zkis: so, a sending API
... and a synchronize()

sicking: i don't understand the disagreement on simpler filter + synchronize()

gmandyam: this is independent
... MessageCursor and MessagingCursor

eduardo: it's a typo

suresh: to me, it seems
... i was involved w/ messaging in DAP
... there were discussions on scope
... what do web apps do
... is it creating/sending messages
... or creating a messaging app
... a lot of thing on the table right now
... not just sending messages
... it seems like the target is building a full sms app
... is there a way to create categories of UCs
... say someone just wants to Send messages

zkis: my proposal was
... to use Telephony style
... which only gives you notices
... we could do the same thing for messaging
... but sicking asked for filtering

suresh: if we create an api
... we have to ...

mounir: if we have an implementer who only wants to implement part
... we could split things out
... given our api, we don't need to split things out, since the Asynchronous bit allows error handling for permissions

Marcosc: from a JS developer perspective
... there are a lot of interesting patterns in this api
... this abstract filter
... a lot of these objects end up in global scope
... MesssageFilter has no constructor
... abstract filter is very Java-ish, it doesn't sound very web-api
... if you define something in WebIDL, it ends up in global scope

sicking: i'd collapse sender and recipient [as contact]

Jungkee: it should probably be a dictionary

Marcosc: yes

mounir: the topic is message filter and datamodel

Marcosc: we need to look at things from JS developer perspective
... eventually we'll have to collapse some of these things

<Marcosc> http://messaging.sysapps.org/#idl-def-AttributeFilter

zkis: i claim we could use AttributeFilter

sicking: i'd caution against doing something that creates optional feature

chris: it's optional if you say "these fields are supported but an implementation may support more"

sicking: optional features are bad for interop
... Contacts is only a Datastore
... you can't remove the Datastore from it
... i don't think we'll be able to solve this here

<joseCantera> +1 to Sicking's proposal

sicking: i stand by a proposal for Synchronize() and a simple filter
... contacts is harder
... you want to search on everything
... the basic filter is on everything

[ Discussion about why Interface should be Dictionary in a bunch of places ]

sicking: i don't like creating something *so* minimialisitc
... that everyone has to build additional proprietary extensions

zkis: do you want to support combining filters?

sicking: i'm happy to do anything for which there are UCs and that is implementable

eduardo: what specific apis does this synchronize() api apply to?

sicking: Messaging, Contacts, and potentially Call Log

gmandyam: how does a Dual SIM option work?
... there's a service id thing

<Zakim> joseCantera, you wanted to say that the "sync" approach could influence over other methods in API. for instance, getting a set of messages by ids

<gmandyam> Dual SIM filtering options are indicated by the Service ID field.

joseCantera: it might not have the message data
... we might have a getMessages(listofmessageids)
... and similar for Contacts
... if an application isn't duplicating content, but only indexing content

<eduardo> http://contacts-manager-api.sysapps.org/#contactfindoptions-dictionary

[ this is still Filtering, but in Contacts API ]

eduardo: this is the same filtering as in messaging

mounir: what are the differences?

chris: there is no composite filtering

eduardo: we don't have `name` or other attributes
... it's a bit more general
... the app specifies the filter value
... and the attribute on which to filter
... and the operator
... and there's a limit on the result count

chris: i have comments, but they're for the api itself

sicking: the filters here seem implementable
... contains may be hard w/o building large indexes
... contains is what people will want

eduardo: what about starts with?

chris: i have a UC where this isn't sufficient
... i click the "to" field in an email
... i want a quick way to find all contacts that have an email
... i need an exists

sicking: i don't know vCard well enough
... there's some sort of instant messaging

zkis: IMPP

sicking: if i want the nick for a particular IM network
... i do it for Skype contacts
... you also can't do that w/ this
... it's part of an array inside a field

chris: i think it isn't in the api
... it's just a string
... if you have the same username for different service names

zkis: you can have two types in one contactfield

chris: even skype+google

sicking: in FirefoxOS
... where we have something like this
... i don't have a proposal
... for contains, on email and skype examples
... i don't have a proposal

eduardo: if we filter on a particular attribute
... we should search on value and type

sicking: that doesn't let me search for all contacts that have email address

chris: the way we addressed this in Tizen
... is search on IMPP.type

sicking: how do you index all of this?

chris: i'm not saying it's efficient
... it's probably inefficient for many cases
... obvious cases will be optimized
... and others will be slow
... and that isn't acceptable

mounir: is there an intent to merge search in Contacts and Messaging ?

sicking: my proposal is ...
... to have a synchronize()
... and a simple filtering mechanism
... with that filtering mechanism being different between Contacts and SMS
... the common UC of searching contacts is different from sms

zkis: what is the relationship between synchronize() and filters

[ chair falls through floor ]

[ sicking stands ]

sicking: the less data copied, the better
... it uses storage
... for SMS, if we can have the SMS app only do synchronize() and datamunging and thread overview
... and have threading based on simple threading, great
... if not, it will do everything
... we'll still have get-message-by-id

zkis: i've made six or seven alternate specs
... people didn't like it
... if you have to create a database for searching
... and maintain a synchronize()

sicking: there's no API that supports the UC
... that supports:
... 1. is performant enough
... 2. supports a wide range of UIs
... 3. is very simple

zkis: what do we choose?

sicking: the two first are hard requirements
... the standard needs to be flexible on UI it supports
... and it needs to be performant
... so i think we need to sacrifice simple
... so i think we should create a JS library
... i don't think we necessarily have to create a JS library
... but it would be nice

zkis: let's fix this before dinner

mounir: i don't think we'll get progress today
... maybe you guys should work together
... but offline

gmandyam: i assume you can't do a find operation on sim contacts

zkis: it's a feature of the past

chris: the spec doesn't say contact origin
... there's a flag for a readonly contact
... an implementation could expose readonly

zkis: SIM contacts is a feature of the Telephony service

mounir: Contacts API is a Store of Contacts
... any other store is not part of contacts api

chris: that wasn't clear to me

eduardo: that was my assumption
... the api doesn't deal w/ source/dest, so ...

chris: how do you handle online services?
... that's in the spec

sicking: full text searching is something everyone will want
... but full text is fuzzy
... you might want to search w/o worrying about umlauts
... and you might want to handle uppercase/lowercase

Marcosc: doesn't this go back to indexedDB?

sicking: we decided it was too hard
... push to v2
... and for v2, we think we want to go to application logic
... for fuzzy logic
... and only add support for a reverse index
... i don't know what the solutions are for searching for Contacts

Suresh: on SIM card
... can you filter based on types of contact?
... i saw in Messaging a notion of an account
... i think it's a good idea to be able to filter contacts based on a service

chris: we have IMPP

mounir: should we be able to filter contacts based on origin
... I have Facebook friends

zkis: you have a messaging service that provides contacts
... you'd have another api

mounir: we don't have a way to specify multiple origins
... sicking will send a Synchronize() api to the ML
... i can't cover filtering

zkis: so UCs would be useful

Jungkee: i'd like to bring the Pick Contact from DAP
... it handles data from Yahoo!/Facebook

<mounir> RESOLUTION: https://github.com/sysapps/sysapps/issues/59

Jungkee: sends a filter to the service and a count limit
... and the service deals w/ this

zkis: you can implement this ContactsManager (it's an interface)
... your implementation could have a separate ContactsManager
... if you must have multiple databases
... you must have multiple contacts managers
... i have a Chat service
... you have contacts that come and go
... i see a valid UC for distinguishing contacts
... do we need a mechanism for fetching...

eduardo: to wrap up
... basic filtering in Contacts remains as is?
... and messaging?
... filtering implies optional filters
... do we stick to messaging filter?

zkis: we need to reduce that filter

sicking: i'm happy to send a proposal for a synchronize()
... and what i think should be filter for messaging

thinker: if i want to find Jonas
... and i want to find him, but he's in Twitter and Facebook
... i just need his address
... the information is that the data comes from one of the datasource
... there's no synchronization issue
... the only issue is if i add a new friend at Facebook
... need to ensure that the friend
... is mapped to the correct contact

chris: i think we should let the application deal w/ merging data from services
... we tried to do this meta contact api
... it's really complicated

zkis: there are transient contacts too

chris: i don't know if we need to handle transient contacts
... i don't think we should support transient contacts

zkis: how do we support chat?

[ Lunch ]

Messaging

<mounir> Messaging API

eduardo: this api allows access to all the messaging technologies
... when you want to deal w/ messaging, you need a way to find messages for both sms and mms
... deleting messages applies to any type of message
... we have a method to find messages and conversations (as discussed earlier)
... you can delete by id
... and mark a message as read
... mark conversation as read marks all the messages from the conversation as read

dsr: can you mark a collection of messages as read?

eduardo: not in this version

zkis: we decided to drop that

joseCantera: if we go to the snapshot approach
... we'd probably need a way to do it to a set of messages

mounir: the FirefoxOS
... would need to do a lot of work to mark a thread as read

zkis: it used to support mark array as read

eduardo: we thought mark conversation covered that UC
... there was potentially difficulty involving marking messages as read for an array

zkis: because you have to confirm
... and what if some succeed, and some fail
... is it a transaction?

joseCantera: i think you can know how many succeeded

zkis: so it would be part of the future
... but there's a need from developers to mark multiple messages

mounir: even if you keep markConversationRead
... you might want to mark all messages before a date as read

Josh_Soref: BlackBerry supports that

sicking: is there a reason not to be a transaction?

kenneth_: isn't it an uncommon behavior?

zkis: transaction complicates it more
... if one message fails, it prevents you from using the whole database
... in the DOMFuture, you'd get a list of the failed identifiers

[ chaals arrives ]

eduardo: if we get rid of the conversations functions, then i guess we need arrays for delete and mark

<Marcosc> http://messaging.sysapps.org/#messagingmanager-interface

eduardo: then there's messaging manager
... sicking suggested getting rid of the MesagingManager and folding those functions into SMSManager and MMSManager

sicking: it's more painful to edit the spec, but it's easier to read

anssik: if we aren't planning to add new messaging types
... we shouldn't plan for this

zkis: we could have Chat and Mail

sicking: it's an editorial issue

chaals: i'd like it to be left split out
... but i won't die on that hill

eduardo: no consensus, leave alone
... there's a type and a serviceIDs field
... maybe we should keep track of serviceIDs

joseCantera: the semantics of serviceIDs need to be clarified
... we need to distinguish between ever seen, have been present, are active

zkis: we tried to do away w/ the messaging service object
... that object would have solved this

joseCantera: the message has sender and recipient

zkis: we agreed to use the iccID (?)

joseCantera: if i change sim and the phone number is the same
... does it make sense to distinguish the messages?
... from the user's perspective, they don't care

zkis: you can distinguish by sender or serviceid

joseCantera: the intention is to service multiple sims
... not sim swapping
... Josh_Soref introduced a problem
... sending a message w/ sim 1
... sending a message w/ sim 2
... and i change the sim
... i see ...

zkis: but you store both

sicking: why do we store the service id?

zkis: i have different charging things

anssik: some platforms let me select sim store or phone store

suresh: can you store messages on sims?

anssik: yes, mostly dummy

chaals: i have messages and it says which sim card it was sent on

mikko: message store is unified
... and at sending, you choose

zkis: it's done this way

eduardo: specifying serviceid is needed for sending

spoussa: you need it for sending

eduardo: but there's no need to keep track of it after

mikko: huawei/android always show sim1 / sim2
... on windows phone, it either with default channel or channel it came

eduardo: deleteAll() is deleting all the messages from the ...

mikko: there's no reason to change

sicking: deleteAll is syntax sugar
... it seems early to add it

<joseCantera> proposing rename deleteAll by clear

sicking: i can imagine wanting ui to do it

<joseCantera> to be consistent with the rest of APIs

sicking: but i can imagine wanting to delete other things
... all from your Ex-girlfriend
... there's no syntax sugar

zkis: deleting by filter is sugar

sicking: why is that more...

mikko: if you borrow
... you might return by restore-to-factory-defaults

zkis: what would it do?

mounir: then maybe you should remove that

Marcosc: is it really that common?
... on my iPhone, i delete by Thread
... talking about UCs
... I want to delete for my Ex Girlfriend
... just because we can do it

sicking: every feature is to support UI
... none is to support backend implementations to do things

zkis: backend is very wide

sicking: the goal is to add API to support various UIs
... there are a million things UIs could do
... we can't possibly add

zkis: this helps performance

sicking: we should do it for things that are strong and common UCs

Marcosc: why not have deleteArray()

chaals: the application logic will provide interface for select girlfriend

sicking: we have a delete() method
... you have a query for messages
... and combine that

anssik: on serviceID
... it's a string, not human readable
... back to mikko
... you'd show "Sim card 1"
... you'd probably display the mobile number of the card
... or operator name
... is this api designed for that common UC
... it doesn't make sense to show the service id

zkis: you'd have a display name and a service id

anssik: the mapping is fairly straightforward
... i have sim cards 1 and 2

zkis: the developer has to map it

chaals: my phone
... asks me
... please tell me the phone number
... it doesn't know

mikko: the service id is probably the best idea
... you can also swap sims 1 and 2
... same in Nokia and Qualcomm dual-sim

anssik: how can i know it's a unique identifier

joseCantera: in Josh_Soref 's UC
... if i change the SIM but the phone number should be the same

anssik: i change the SIM to a different size
... or carrier

mikko: the service ID shouldn't be the sim card
... even if the operator upgrades from small sim to big sim
... or upgrades for security

zkis: the only thing that's unique is iccid

gmandyam: i think you need to add informative text to explain how service id is constructed
... you have sim_sms_1
... i'd say "sim1"

zkis: different providers can give you...

gmandyam: you have different interfaces for sms and mms
... your example shows this

<genelian> mounir, yeap my answer has been answered

zkis: sms_sim1 there is a bug, it should be iccid

<eduardo> http://messaging.sysapps.org/#widl-MessagingManager-serviceIDs

<Zakim> chaals, you wanted to say there is a need to keep track of where you sent something from

chaals: there's a need to track the number from which you sent messages
... i track which conversations are business, which are personal
... which numbers people have

eduardo: are these UCs covered if you know the number of the sender

chaals: you need to track something

eduardo: you may have two different sim cards with the same number
... then the important thing is the number, not the sim id

zkis: the same sim can have multiple phone numbers

eduardo: from my perspective, the most important thing is the phone number

mounir: I went to the operator
... and they gave me a sim for the operator
... and then they transfered my number
... which caused my sim to have its number replaced

<Zakim> joseCantera, you wanted to propose rename deleteall by clear

zkis: for email, you have distinct storage per identity
... you'd only want to delete for one service
... with multiple sims...
... clear() is fine as a name
... i'd like to maintain an optional parameter for serviceid

sicking: is there a reason why
... most of message management is currently on Message...
... forget interface name
... managing stored messages is on
... ....
... then odd ones like deleteAll

zkis: you could have simultaneous incoming
... each on each service

sicking: you could fire separate events

zkis: all code i've seen in the past treated things distinctly

sicking: as long as we have other message management in a central place
... it seems appropriate to notify in the central place

zkis: for incoming, they're separate
... you implement SMS, IM, MMS
... you don't want events from IM to choke the SMS

sicking: it's single threaded

zkis: you're right

sicking: everyone treats sms/mms the same for incoming
... it's easy to handle in the event handler

zkis: how do you expect it to work for email

sicking: i don't understand how we'd add email to this
... if we'd have the same point for reading
... i'd want the same

zkis: ok

Suresh: the class names are confusing

Marcosc: MessagingManager should be MessageManager

<mounir> ack

eduardo: rename Messaging to MessagingManager
... and move the current MessagingManager to the SMSManager/MMSManager

Marcosc: use Nouns for interface names
... don't build object hierarchies

zkis: even at the cost of repeating properties

eduardo: some of the descriptions of MessagingManager are different for SMS/MMS
... so it would help

[ eduardo shows the distinct SMS and MMS text for "receivemessage" ]

[ and "delivery report reception" ]

eduardo: the only one with common is deleteAll, which may be removed from the spec
... so no harm to move it

<Zakim> mounir, you wanted to ask if using objects wouldn't make things better?

mounir: i'd like to ask if you want to use a more object oriented model for messageID

zkis: do we have default value?

mounir: say i have two or more sims
... and i want to use a specific sim
... i'll have to pass that value everywhere

zkis: i used to have the object
... it was killed
... messaging service was an object itself
... - sending, storage, retrieval
... with properties for service provider, identifier
... you enumerated messaging service
... i thought it made sense
... but i was alone on that

mounir: i would prefer that

zkis: i have a spec for that
... it's a more correct design to have the service as the abstraction
... so we reopen discussion on that
... it was dropped at an editors meeting

joseCantera: yeah
... you could have message notifications on each object

mounir: in general, i like having those objects

genelian: in 13....
... there's a distinct bit

eduardo: there's a not-fetched thing

<mounir> SmsMessage Interface

eduardo: i proposed getting rid of messagingmanager
... and put the bits into sms/mms

zkis: same logic should be applied to message

eduardo: MmsManager has send() and getch()
... and get or set FetchMode

zkis: I had a spec where there was an MmsManager instance per serviceid

Josh_Soref: that makes more sense to me

chris: there's no reason to have DOMString[]?
... why not just DOMString[] with it being 0 length

thinker: is it possible
... for an application to add a new message to the database
... like Facebook/Twitter
... on the ML, people said they don't want this to be a generic messaging service
... but that would make it more useful

Josh_Soref: is there some logic on `MmsFoo` v. `MMSFoo`, c.f. DOMString, XMLHttpRequest

zkis: what's the UC?

genelian: Twitter/Facebook/Skype
... insert the messages into a single place

<thinker> https://wiki.mozilla.org/WebAPI/AppDefinedTeleophony#Messaging_API

zkis: the n900 had a unified interface
... for sending a message, i need a recipient, message, serviceid
... this covers >90% UC

mounir: we can already do this on the web

sicking: let's move on

<chris> http://messaging.sysapps.org/#message-interface

[ eduardo reads Message properties ]

eduardo: if we design a testing framework and have no apis

chris: based on the description, "timestamp" is meaningless
... received, created, sent, ... it's vague

<chaals> [+1 to Chris]

chris: plus it's a Date
... it's a send date
... `read`
... i'd expect isRead

sicking: we rarely have is in bools (isTrusted)

eduardo: for received messages it's the time it was sent
... the date of the message
... for SMS
... is the date the SMS reached the recipient's message center

<chaals> [seems there are more than one relevant dates. Like other kinds of messages...]

<anssik> rename 'timestamp' into 'sentDate'

mounir: you can manually add items in the spec or github

Marcosc: you do biblio.id

chris: you have `sender` in message and `recipient`
... but you have `to` in MMS
... maybe you can have `from` and `to` in all ?

<anssik> e.g. File interface has a lastModifiedDate attribute that returns a Date object too

mounir: yes, better to use `to` / `from`

zkis: fine

gmandyam: what is FetchMode used for?

chris: you only Fetch in manual mode

zkis: MMS, you get a notification
... if you set automatic delivery
... then you get a link, and you're supposed to fetch it from the server

Josh_Soref: people should not be forced to read the MMS standard to use these APIs

lgombos: +1

zkis: we can mention this

eduardo: a high level description

gmandyam: where is the MessagingRequest object passed

zkis: that's a DOMFuture thing

Marcosc: when you have steps, name them and put definitions on them
... so we can link to them
... when the fetch method is invoked, it runs the "steps-for-fetching"

Josh_Soref: what is "unique in the frame of the user agent"

zkis: it's unique on the device across all the services

genelian: i didn't see any system message behavior
... if my app isn't yet launched, do i not get notification

mounir: maybe you should file an issue about waking up a messaging application

<JonathanJ1> Do we need the Pending Time Period in MMS/SMS send method ? (Section 8. SmsManager, Section 10. MMSManager)

JonathanJ1: sometimes you want to ask a message to be sent later
... in an hour, the next day at 10 am

<JonathanJ1> I think similar feature is PendingIntent attribute of Anroid sendDataMessage - http://bit.ly/KlQXhi

eduardo: it's a corner case

sicking: you can use the alarm api

joseCantera: that's a hint for the sms delivery center

eduardo: if we want to expose the full SMS/MMS api
... it would be really complex

chris: [mumbles] CC, BCC

eduardo: the feature is in SMS

[ eduardo describes 13.1 ]

mounir: state strings should be enums

sicking: 14 DOMString? deliveryStatus[] should be DOMString[] deliveryStatus
... why is `smil` Document
... MMS uses a subset
... if it really needs to be parsed, it's easy for a document to use DOMParser
... a lot of MMS messages are a simple format
... i'm worried someone will advocate implementing the SMIL DOM
... it also means never exposing this API in Workers

joseCantera: i'll open the issue

chris: why can i send an MMS to multiple people
... but not SMS

sicking: if you send multiple messages, you'll get multiple fails
... or delivery status
... what happens if you have the same guy in `to` and `cc` ?
... i'm not sure the API works

- DRAFT -

SV_MEETING_TITLE

10 Apr 2013

Attendees

Contents

Alarm API

Data Model and Filtering

Messaging

Summary of Action Items

Scribe.perl diagnostic output