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

Explanation of how to use meeting

<scribe> Scribe: Josh_Soref

<scribe> ScribeNick: timeless

Agenda

mounir: good morning everyone
... the first thing we should do is an Agenda Review
... i know people have things they might want to change this

[ mounir goes to find Microphones ]

<JonathanJ1> http://www.w3.org/wiki/System_Applications:_2nd_F2F_Meeting_Agenda

[ Microphones arrive ]

mounir: can you hear me better?
... comments on the agenda?

zkis: are we fine with the agenda?

anssik: about Task Forces
... do we want to fill in the blanks tomorrow, or do people have proposals?

zkis: Messaging, Telephony, Contacts could be one group of people

mounir: if people want to do that, we could do that
... but we should do that tomorrow before splitting into groups
... Anything else for the Agenda?

Josh_Soref: I'm Josh Soref, BlackBerry, i'll be your scribe today

marcosc: Marcos Caceres, Mozilla, I edit a few specs including App URI and helping zkis with telephony

spoussa: Sakari Poussa, Intel, I work on Tizen

kenneth_: Kenneth Christiansen, Tizen, I work on the web platform

zkis: Zoltan Kis, Intel, I work on Telephony

gmandyam: Giri Mandyam, Qualcomm Innovation Center

Dong-Young: Dong-Young Lee, LGE

Joonhyung_Kim: Joonhyung Kim, LGE

Oliver: OliverX, Gemalto

kjwallis: Ken Wallis, BlackBerry, WebWorks

<opoto> Olivier Potonniee, Gemalto

darXX: XZ

<dsuwirya> dsuwirya: Darmawan Suwirya, Gemalto

genelian: Gene Lian, Mozilla, QQ

JonathanJ1: Jonathan Jeon, ETRI, most apis

lgombos: Laszlo Gombos, Samsung, Tizen

Claes: Claes Nilsson, Sony Mobile, I'm the editor of the raw socket api

hsinyi: Hsin-Yi Tsan, Mozilla

thinker: Kui-Fong (Thinker) Lee, Mozilla

dsr: Dave Raggett, W3C, the staff contact for the group, here to help make the group work well

anssik: Anssi Kostiainen, Intel, trying to get specs forward
... willing to commit a lot of time to get things done

Chengyan: Chengyan Zhang, China Unicom

Bo_CHEN: Bo Chen, China Unicom

Marta: Marta Px, Samsung

Janusz: Janusz Majnert, Samsung

wonsuk_: Wonsuk Lee, Samsung, CoChair, interested in most topics
... i hope that we can talk about time frames of specs in this meeting
... we embedded the schedule in the charter
... even if we make good specs, we also need to consider timeframe

jungkees: Jungkee Song, Samsung, interested in all APIs, but especially Runtime and Manifest

Daniel: Soohong Park (Daniel), Samsung, interested in AA

mounir: Mounir Lamouri, Mozilla, CoChair

App URI

marcosc: i think the spec is ready for LC
... i don't think there are any outstanding technical issues
... just looking at what's left in github

mounir: we're just trying to say "hi, i'm here" ... not go into too much detail

marcosc: these are the only issues needed to get to LC
... big thank you Marta for help with the test suite
... we received an offer from a person who put together a URL test suite
... it's fairly extensive

<JonathanJ1> http://app-uri.sysapps.org/

marcosc: it was reviewed by anne, the editor of the url spec
... we'll see if we can layer our tests on top of that
... i'd like to look at layering this spec with the Fetch spec
... Fetch defines how to fetch stuff
... in terms of Web Architecture, it'd be good to instead of redefining
... integrate with that
... to interoperate with what's in the platform
... it isn't necessary to do that, because the spec is self contained
... i don't think it'd affect conformance
... i need to talk to anne about that
... hopefully within the next month or so, we could publish it as LC
... anyone have any comments?
... is anyone apart from Mozilla interested in implementing this spec?

zkis: how do address other applications?

marcosc: other applications aren't covered
... it's only for addressing resources within your package
... there is no means to address another application
... mozilla is currently... but not specifically working with that
... defining an Origin in the manifest for privileged apps
... which lets apps interoperate with the web
... which lets apps work with CORS/other technologies

mounir: is that Origin random?

marcosc: no, that origin is set by the developer
... if you don't specify it, you get a random origin
... right now, i don't think we have a way for one app to communicate to another
... it's very easy to forge
... it requires a centralized registry to get it to work
... it's ok with FirefoxOS, it's a proprietary platform, it's centralized

kenneth_: does Chrome have something similar?

marcosc: I think it uses chrome-app:, but it's essentially the same
... i don't know if they have HTTP responses
... we fake HTTP responses (404, etc.)

anssik: some people may not remember the widget: uri scheme
... can you highlight the differences?
... can the people on the line hear?

marcosc: the differences are purely cosmetic-- find and replace
... s/widget:/app:/g
... all that feedback is already in the spec

anssik: this is rebranding, it's already been scrutinized (in WebApps)

marcosc: yes, but with a Test Suite, and a TAG review

anssik: do you have Implementation Status from widget:?

marcosc: since we published it as a Note, I don't think we have that list

mounir: what's the implementation status of app:?

marcosc: it's only Mozilla, but there are some bugs

Marta: 6 failed out of 20 tests
... and something for Tizen based on file:, but even worse

marcosc: only us at the moment

mounir: about Origin
... according to the spec, Origin is random
... but Mozilla had issues about that
... because the security model of the web is based on origin

marcosc: uuid is only a recommended, it isn't mandated
... i'm going to change the example to make that more clear

mounir: mozilla's solution was to add origin in the manifest
... and a reviewer would have to approve that
... so if you have a Google Maps app, the reviewer could say it matches maps.google.com and approve
... where would Origin specification be?

marcosc: it would be in the Manifest spec
... but i should add a note indicating that it's outside the scope of this document

gmandyam: there's a normative dependency on Mime Sniff
... i've gotten conflicting feedback from W3 on normative dependencies outside W3

marcosc: that's why i'd like to layer it on Fetch
... I think Fetch already has to deal with that
... I'm not sure if URL is going to deal with it
... there's also CSP
... there's a lot of intermixing
... you're right, the thing's a mess
... the story for mime sniffing is a bit of a mess

gmandyam: I looked through XHR2

<anssik> [for reference, pub history of the Widget URI scheme (now a Note) that predates the app URI scheme: http://www.w3.org/standards/history/widgets-uri]

gmandyam: XHR2 had a reference to Mime Sniff, but it was informative
... you could follow their approach, of using informative

marcosc: i think that might be ok

<mounir> ACTION: file a bug about maybe relaxing dependency on sniff [recorded in http://www.w3.org/2013/08/27-sysapps-minutes.html#action01]

<mounir> ACTION: make it clearer that uuid is not a hard requirement [recorded in http://www.w3.org/2013/08/27-sysapps-minutes.html#action02]

gmandyam: today developers live with sites that don't follow Sniff

marcosc: Sniff applies on the client side

gmandyam: app developers trust that content types are set correctly

marcosc: the trust is that something resembling Sniff is active

gmandyam: but it might not be Sniff

marcosc: the assumption of using a hard dependency is to guarantee Sniff
... relaxing it will give you this pain
... consider you're using a Proxy
... if there's Sniff, it promises to use Sniff's magic number checks for binary types
... you're guaranteed the appropriate behavior if you have a Must
... it does have a semi annoying behavior that it's a semi living document

gmandyam: you can verify this in testability

marcosc: that's the idea

gmandyam: then you could say recommended, and rely on verification

marcosc: i'll have a look at what state it's at
... for Mozilla/WebKit, they already implement Sniff
... i don't know how consistent they are, i don't know the level of interop
... but i suspect it's fairly high
... i don't think it matters if we relax it or make it stronger

zkis: you could give a location to get a file
... can you access contact objects?

marcosc: no, this is just retrieving resources stored within the application package
... other objects may define their own ways of being addressed
... we might even define a way to address contacts or others

<Zakim> mounir, you wanted to ask about Fetch and W3C standardisation

mounir: -> http://fetch.spec.whatwg.org/ Fetch -- will this be moved to W3C for standardization?

Josh_Soref:

marcosc: i trust that anne will do the right thing
... i think they're doing the thing in good faith
... these specs will need to move to W3
... especially if Navigation Controller will depend on Fetch
... when Navigation Controller moves to W3
... I spoke w/ MikeSmith, and he said Navigation Controller would be a good fit to move to W3
... that's a replacement for App Cache
... i'd assume its dependencies would come along

mounir: Is anyone here interested in implementing that spec?

kenneth_: we have a patch for it internally

Josh_Soref: I believe Cordova is/has/will be

mounir: do you know if we can get Google to implement?

marcosc: i don't know, they're using it for Extensions and Packaged Apps

<mounir> ACTION: contact Google to see if they would be interested to implement this specification [recorded in http://www.w3.org/2013/08/27-sysapps-minutes.html#action03]

marcosc: i'd like to get a resolution to move this toward LC

<anssik> +1

<Marta> +1

<jungkee> +1

mounir: some people want to access Zip files
... what would be the difference between the app: and direct access to a Zip file

marcosc: there have been numerous attempts to do this over 20 years
... addressability of
... with a Zip file, you could get the files
... or get a file from inside the server
... it should be completely transparent
... like a #!/ to get the file you want
... i don't think you should use a uri, just http
... zip file #! /

mounir: close to the jar: scheme

marcosc: the fallback solution there is, if it doesn't support the type, it just requests it from the server
... or it could be clever and download the file locally and address the file as if it's http
... how it handles mime types gets complicated

mounir: one of the main reasons for app: was for security reasons
... the origin for jar: was the origin of the .zip
... but origin: for app: is random which protects the site
... this seems like the main difference between direct access
... but if origin randomization isn't a mandatory bit

marcosc: app: assumes you're starting from a local non-web environment
... but a larger way of accessing assumes you're starting from the web and accessing inside
... that would be the main difference

Josh_Soref: the problems mozilla hit were that people could smuggle .zip content into random file kinds
... which violated the security assumption of file hosters
... Microsoft got hit by that w/ .chm
... And then there's Google's headache where there were two ways to index .zip files, and they validated the way they weren't accessing, which was (and still is) a huge security hole

jungkee: gmandyam talked about WhatWG's XHR2 Mime Sniffing. Because it's outside W3's context, that's why there isn't a full reference in the URI spec. But XHR2 doesn't refer to Mime Sniffing -- It uses overrideMimeType()

marcosc: XHR does a bunch of overrides
... it does a lot of rewriting of mime types

Raw Sockets

Claes: i think we're expecting remote participants
... what about sicking?

Task Scheduler

lgombos: chris, can you hear us?

chris: yes, i can hear you

[ we can hear chris too ]

lgombos: i think someone should try to drive the discussion

marcosc: chris, i'll try to drive the discussion
... the spec has been renamed from WebAlarms to TaskScheduler

<lgombos> largest outstanding issue - https://github.com/sysapps/web-alarms/issues/46

zkis: because the change of context, it doesn't really deal with time zones

marcosc: not as much as it did before
... not in the web that you'd expect a calendar application to support time zones
... Marta did a formal survey to find out if anyone understood respect/ignore-timezones
... no one understood
... mounir did a grep on Firefox OS
... no one understood there either
... they used the wrong one
... the first big issue is
... do we want to support the Calendaring UCs or not
... should you be able to build a Calendar app on this?
... let me frame it differently
... to make this useful for Time Zones
... you'd want to be able to say "remind me of this meeting that's happening at 5pm GMT+5"
... whether that's calendaring, it seems useful to be able to do that
... although that seems useful, whether people will implement that, without falling back to the system to handle that complexity
... you need to deal with time zones
... Josh_Soref brought up +13, and +:15
... you need to define a micro syntax for timezones

<lgombos> initial implementor feedback form blink-dev - https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/kbBbordYkjk

marcosc: plus leap years, DST
... the OS usually handles that
... i imagine a lot of that is solved

Josh_Soref: countries like to screw that every year

marcosc: it's whether it's feasible

zkis: date doesn't support time zone

mounir: Date knows its timezone, but doesn't let you set one
... some people want to remove date from the web
... you add an alarm,
... if you create an alarm now, the system will know you're in Toronto
... the system knows that
... but you might want to say "9am" or "9am in eastern tz"
... we could pass a milliseconds since epoch
... and pass a string "America/Toronto" or nothing (UTC)
... it's a bit more painful
... you have to handle ms
... but ECMAScript thinks no one should use Date
... then you have no tz except UTC

Josh_Soref: +1

marcosc: the ECMAScript guys said don't use Date
... and WebIDL says it's AT-RISK
... to me it seems horrible

mounir: that's what people in ECMAScript want us to use

marcosc: ms is just a number? ok, yes

Josh_Soref: you only have Date.now()

marcosc: you say Date.now() +/- x
... at this time in ms, in this timezone (GMT+5), do this

zkis: this is fine for short events, but for recurring

<zkis> this is fine for one-shot events, but NOT for recurrent events

Josh_Soref: there's an approach where you schedule callbacks for a couple of the likely timezones (the earliest one, perhaps 4 or 12 hours later)

<chris> mounir, for now yes

Josh_Soref: you wake up at the first callback, you check your timezone, and decide whether the event will happen soon in your timezone, if so you set a new event for shortly before the actual right time

<chris> but at the moment, nothing is happening right?

Josh_Soref: if it's "now", you do your real work
... if it's later, you sleep
... this is easy to explain, and any repetition logic or complex repetition is handled by your code scheduling for the next date, be it "4th monday of the month" or "last monday of the month"
... it's a series of one-shots, but if we promise to call you at some point, you're fine, no need to schedule all of them, a few will do
... easy to explain, easy boilerplate for the scheduling
... and easy to integrate the complicated app specific repetition logic

gmandyam: this was never intended to be a Calendar API
... we established that early on
... if you want to do a Calendar API, you can look at DAP
... it's quite complicated
... i personally object to us making this a requirement for this API, i think it's outside of scope
... i think the discussion of recurrence is nice
... i agree with Josh_Soref, an application can do this with the existing API
... we can come up with code examples all day long
... for the spec, i think we only need minimal examples
... i think we have sufficient time zone examples in the spec
... chris put them in the spec based on Josh_Soref 's and my comments last fall
... i don't know why they keep coming up

marcosc: because we see it in real apps
... it's a problem, people don't understand it
... when Marta asks a small set of developers "do you understand this"

mounir: the spec is clear
... but people don't read the spec
... if you want to use an API, you read a tutorial, or copy-paste
... that parameter is not intuitive at all

gmandyam: the HTML5 spec is sparse
... but there's an article on HTML5Rocks
... that could be one approach, if someone's willing to do it
... but answering developer confusion in the spec
... if developers are giving it a quick once through

marcosc: i read through it, implemented it, and got it wrong
... i consider myself an average developer
... i'm not representative
... what we've seen is that it shouldn't be so bad
... chris has proposed alternative names (followSystemTimezone / useSystemTimezone) it may be more clear
... we need to test it on people
... i take ergonomoics of APIs very seriously
... we strive to make APIs as usable as possible
... even if it takes more time

mounir: at mozilla, APIs have to be self describing
... you just read the IDL, you don't read tutorials
... that argument... it came from _us_
... in the beginning, we had a boolean, it was even worse
... we switched to a string, but people didn't understand the string
... we're to blame, it was our idea
... we want to fix it

gmandyam: is this syntactic sugar?
... as long as the functionality doesn't fundamentally change
... but people in this room were reviewing this

marcosc: we're willing to spend extra time
... we want it to actually make sense
... i think we have agreement that Calendaring is not in scope

mounir: i think Recurrence is not an issue
... i think we should still consider writing a Calendar app based on the API is a UC, but it shouldn't be "easy", just "if you want to, you can do it"
... you should be able to fire an event using the Task Scheduler API

zkis: once we agree that the API isn't recurrence, why have TZ at all

<lgombos> +1 to what mounir just said

mounir: for One shot, time zone is very useful
... the first UC is i want "7:30am"
... the second is that i woke up at 7:30am on the second day in Toronto (first day in London)
... but if i have an event with my manager

zkis: do you need to deal w/ timezones at all?

mounir: the other issue is that you have to fetch time zone definitions
... the system could take care of that for the app

zkis: if you decide to include timezone, it's one step to recurrence

mounir: i don't think they're related
... `7am` M-F, and `9am` Sat
... i think recurrence and timezone are different problems
... you don't seem to agree

marcosc: i tend to agree with zkis
... it's a step to add all sorts of things, but it's up to us to limit it
... Respect the timezone, but when you specify the timezone for the alarm, it also gets complicated

zkis: there are events that update when timezone shifts or not
... and others that don't
... but at that point it's a calendar api

mounir: maybe we could start without a timezone, and see how it works, but reserve a way to perhaps add it if necessary
... i don't know, would Intel would be interested

chris: for TZ support
... is mounir pushing for what's in the spec
... or supporting any TZ, not just the system

marcosc: mounir is asking "can we try without TZs" at all -- initially

chris: what's it do internally?

mounir: ms since epoch
... if you use Date.now(),
... if you create a new Date in 9am, it's 9am in your TZ
... because Date() shifts that to UTC
... Chrome uses Date.now()
... they don't have timezones, but they have repeat

anssik: things should be terminated
... is there something in launchEvent
... with a `reason`
... it perhaps should be closer to the Runtime model

mounir: i thought it was using System Messages

anssik: i see references, but that's very underspecified

mounir: the Runtime spec is using System Messages

<kenneth_> http://support.microsoft.com/kb/325413 : "Methods in these interfaces accept schedule time data in SYSTEMTIME format. The SYSTEMTIME format is not set for any local time zone. "

mounir: i guess the Message would be `Task`

<zkis> I think 2 approaches would make sense: 1. task scheduler with no time zone support (i.e. using UTC), 2. calendar API supporting TZ and recurrence

mounir: to fire every hour
... you create a new task for the next hour

anssik: have you talked about that in public?

mounir: mozilla was discussing with google, bu ti wasn't involved in that discussion

anssik: it would be great to get those individuals to contribute to this WG

kenneth_: we'd like something simple where something more complicated can be built upon

marcosc: i agree

mounir: we need to remove timezone, change Date to ms

<mounir> ACTION: change the Task Scheduler spec to no longer have tz information [recorded in http://www.w3.org/2013/08/27-sysapps-minutes.html#action04]

mounir: anything else?

marcosc: chris added text to support Promises

mounir: on the Promise text, I think you put Promise and then the precise return type

marcosc: that isn't in WebIDL yet
... Promises break Exception handling
... WebIDL is supposed to do the type checking
... but Promised based APIs, you aren't supposed to throw exceptions
... you're supposed to send exceptions to the resolver
... i raised this as an issue w/ webidl
... there's also mounir 's issue
... returning a Promise w/o a type

kenneth_: i know with the Chrome approach, you need to resubscribe to the events on the next load

mounir: why

kenneth_: because it needs the function callbacks

<mounir> ACTION: chris should open an issue so we keep in mind the relation between Task Scheduler and Event Pages [recorded in http://www.w3.org/2013/08/27-sysapps-minutes.html#action05]

marcosc: one model is that pages are kept alive

kenneth_: they aren't workers, they're documents

marcosc: right, they're rebuilt, and shut down
... chris, anything else?

chris: nope

<chris> :)

<marcosc> http://web-alarms.sysapps.org/#taskscheduler-add

If an error occurs, run these substeps and then terminate these steps:

Let error be a new DOMError object whose name is "InvalidStateError" if the date argument is in the past, "QuotaExceededError" if the data argument exceeds an implementation-dependent size limit, and "UnknownError" otherwise.

genelian: the InvalidStateError, for an alarm in the past, i don't think this error is feasible for the API implementation
... we can't check whether a date is expired
... suppose you want an alarm for "7:00:01am"
... and the call is at "7:00:00am"
... the codepath could be processed very fast, possibly in 1s
... but if the codepath needs more than 1s, then you will return an invalid state error
... it's a race condition
... i'd suggest removing this error

<chris> Yes, it is racy..

genelian: and have the system always fire the event if it's in the past

Josh_Soref: +1

<mounir> ACTION: chris should file a bug about the race condition [recorded in http://www.w3.org/2013/08/27-sysapps-minutes.html#action06]

wonsuk_: what's the timeframe for LC for this spec?
... there are no big issues

marcosc: that we know of yet
... i think the next step is to build the test suite
... a small reference implementation

mounir: do we have any implementation?

marcosc: no

mounir: no one is implementing this spec
... not even mozilla

Marta: i started working on a JS impl

marcosc: ... using setTimeout
... there's no real implementation
... LC can mean "we think it's Feature Complete"

mounir: sure, we can move to "LC"
... i don't think it's very important

marcosc: it's important to free up a slot
... to do other work

wonsuk_: yes

kenneth_: i'd like to see how everything works together with the Event Pages model

marcosc: it doesn't exist

<mounir> http://developer.chrome.com/apps/event_pages.html

anssik: can we schedule some time for Thursday to talk about that

mounir: to me, it's part of Runtime/Security

<kenneth_> the event page model in other words

anssik: kenneth_ and i wrote up a proposal

[ Break ]

<chris> bug filed for genelian's comment: https://github.com/sysapps/web-alarms/issues/51

mounir: any more questions about Task Scheduler?

dsuwirya: i was assuming the time would be an Interval
... instead of a thing from epoch
... you want to do something at an interval
... even if you want to wake up the system at a time
... you're more likely to do it based on Now instead of epoch
... it avoids the problem with time in the past
... maybe there's a timezone change event
... and the application takes care of recomputing intervals
... it's good to make the api of the system lightweight
... does that make sense?

mounir: this fixes the race issue
... if you say "make it happen in 1 minute"
... but if it registers very late
... your thing could be fired a minute after it is registered
... i think the race issue could be fired even later
... if you say 8pm tonight
... if you say "register for 10 hours", but if you're under pressure, you could fire at 8:05pm
... i think you introduce more trouble than you fix

genelian: you need time to calculate intervals, so that's another race

mounir: setInterval() has no precision
... it's a common bug on the web
... they don't compute the delta between two calls
... so i think we lose
... i generally don't agree with that proposal

zkis: i agree w/ mounir
... we don't have any way to do guaranteed response times from the system

chris: i'm ok w/ removing the TZ from the specification
... we can't do an alarm clock application
... it's basically a setTimeout that can launch the app

Josh_Soref: if i use an alarm clock, it shouldn't set an alarm for 8am, it should fire for 7:55am, build up enough bits, and then fire the actual sound at 8am. otherwise, if it wakes up at 8am, the alarm will lag significantly

mounir: we discussed a timezone change api
... you can already get timezone changes from new Date()
... i think we fixed the bug w/ new Date() TZ
... you could fire the Event Page

[ there was a discussion where marcosc forgot that this isn't System Messages starting a UI, but Event Pages which start out w/o UI ]

Dong-Young: do we need ms or just s accuracy?
... for most UCs, i think s is enough
... second
... I assume, if we have a task scheduled for 8am
... but the machine is off
... if it turns on at 9am
... will the task be fired?
... do we explicitly mention it in the spec?

mounir: i think we specify that

marcosc: it was guaranteed with system messages (via queuing)

mounir: chris and i spoke about it
... the same problem happens if you change your time manually
... 9am->10am
... i think it's part of the spec

jungkees: that is specified in Runtime

chris: it's part of the examples

mounir: i think we should make that part of the spec

<mounir> ACTION: make clear that a missed alarm should be fired [recorded in http://www.w3.org/2013/08/27-sysapps-minutes.html#action07]

mounir: Timestamp uses ms, it's a standard
... no point in moving
... i'm not sure what precision is promised

chris: i don't think there's any precision promised

<mounir> ACTION: precise the precision ;) [recorded in http://www.w3.org/2013/08/27-sysapps-minutes.html#action08]

<jungkees> For the second question, Rumtime spec says, When a UA is required to fire a system message of a given type, it has to do one of these actions: Otherwise, if the application is not running, the UA MUST add the message to the pool of messages and start the application.

chris: there are already open issues on github

<chris> Specify what happens when several alarms fire while device is off

<chris> Specify behavior when clock jumps past an alarm

mounir: anything else on this topic?

Raw sockets

mounir: i invited sicking to attend by email

<Claes> Raw Socket API

Claes: this API is for apps to communicate over UDP and TCP
... we have a FPWD
... there are about 14 open issues
... some could probably be closed
... this session shouldn't go into too much detail

marcosc: for now, give us a general overview

trackbot, bye

Claes: Section 5 is about UDP
... the next Section is TCP
... the last part is Server
... a few issues to talk about
... one is a proposal to use URLs instead of an address+port
... i'd suggest we start with a discussion on Secure Sockets

<spoussa> Raw Socket API: Support for secure sockets

Claes: what does a web system application really need
... the conclusion is that we should start w/ the simple case
... server authentication
... an attribute is added
... taken for TCP to indicate to use a secure channel
... there's also a proposal to offer startTLS() or similar
... and these would use the default certificate
... i added a proposal for startTLS() or upgradeToSecure()
... i made an attempt to define a Promise based method
... i got comments from marcosc
... basically, this is
... this doesn't require any specific parameters
... so there probably needs to be a way to specify a Host Certificate for each API that handles accepting TLS

<Zakim> mounir, you wanted to ask ppl to register for dinner tomorrow

marcosc: without going into the details of this
... does anyone object to offering a way to secure the connection?

zkis: sicking suggested using PeerConnection
... what's the need?

marcosc: can PeerConnection do IMAP?

gmandyam: the UC is existing backwards compat support

Claes: this is for supporting existing clients

zkis: if we do support Raw Sockets
... then we should support Secure Sockets

Claes: 1. create a secure connection
... 2. upgrade an insecure connection

marcosc: i don't anyone objects

gmandyam: on Upgrade
... are there observed issues w/ proxies?

Josh_Soref: there aren't any differences between this and a normal client using that same proxy
... either the proxy works, or it's horribly broken

RESOLUTION: group supports offering APIs for Securing Raw Sockets - both initially and via an upgrade

<marcosc> async methods should return a Promise

Claes: our Asynchronous methods should be based on Promises
... and then there was a question of.... which methods in Socket are Async, and which are Sync
... the conclusion was that the only really async method is send()

zkis: does it depend on the protocol?

Claes: i'm not sure the benefit/how it would look like to have receive data as a Promise
... i can't see how that would be modeled
... the current design of send() is based on Node.js's Send API
... it looks the same
... Mozilla's Firefox OS api has the same syntax
... we could make this a Promise APIs
... i don't see a difference
... one difference is not using Exceptions

marcosc: Node.js is mostly server side
... i think we need to reach out to them, to get them to look at this
... they've iterated over their APIs quite a bit
... they're pretty confident
... and there are a bunch of libraries that do this as well

mounir: is there an implementation status?

marcosc: we could do a reference on top of node

Claes: i can take an action

spoussa: Intel is looking into the implementation as well

<mounir> ACTION: make an implementation reference [recorded in http://www.w3.org/2013/08/27-sysapps-minutes.html#action09]

marcosc: we should try
... but it does look like it could be promisable

<marcosc> address + port vs uri

Claes: there's a discussion of using a URI scheme instead of arguments for address and port
... i'm not convinced on the benefits

marcosc: i didn't see any strong arguments

Josh_Soref: the configuration of the two pieces is usually fairly far away from the socket bind call, and having to pass them separately can be somewhat error prone
... but i don't personally care

Claes: sicking argues it doesn't give any value
... the application should just do string concatentations to get a url
... my proposal is to leave it for now

marcosc: anne was saying to use URL instead of URI to ensure that things are parsable

mounir: do we need public-script-coord@ to comment?

marcosc: it's more of a TAG issue

mounir: do we need a higher level feedback for this?

marcosc: i'm w/ Claes on not doing that now
... this only covers a small part of URL space... no path, no fragment identifiers -- what does that mean
... it's shoehorning
... yes there's overlap w/ URL scheme
... it feels like a good thing, but you don't really need it
... it's just an address and a port

gmandyam: i think this is an IETF issue
... i think the way he described it doesn't describe sufficiently
... there are a lot more parts to resolution
... i think we should give feedback to the requester about the implementation cost

Claes: general opinion?

gmandyam: close

marcosc: defer -- come back to later... if it fits later

<gmandyam> I think this issue should be closed for 2 reasons: (1) This should be proposed in the IETF, and (2) The resolution of URL's is not addressed in the proposal (e.g. DNS entries, etc.)

mounir: i'd want to reach out to some other group, but defer

<gmandyam> And (2) above also belongs in the IETF

Claes: i'll close the issue w/ a comment

<mounir> RESOLUTION: close the udp/tcp scheme issue

<Claes> http://lists.w3.org/Archives/Public/public-sysapps/2013Aug/0068.html

Claes: Patrick McManus from Mozilla sent detailed comments
... Patrick said please don't use the word "raw"
... that's a well known networking term which is reserved for layers below TCP/UDP
... he proposes renaming TransportLevelSocket

<marcosc> osi-7-layer-model

mounir: make sure you have a filed issue for the rename

Claes: is there any problem with renaming specs?

<mounir> ACTION: file an issue for Raw Sockets renaming [recorded in http://www.w3.org/2013/08/27-sysapps-minutes.html#action10]

[ No, Alarm was renamed without issue ]

Claes: will there be 2 groups tomorrow?

mounir: 2 or 3

Claes: does anyone else have issues to discuss today?

gmandyam: what about TCP NO DELAY?

Claes: yes, that was a comment from Patrick
... yes, i guess we should have that option
... that's just a new field in the dictionary for TCP Options
... i can take patrick's comments and file issues for them for tracking

mounir: what's left to do in order to move to LC?

Claes: the main thing is secure sockets
... I hope to get more support from 4D

<lgombos> can a compliant implementation not have secure sockets supported ?

<Claes> My view is that this is optional but it has to be clarified.

<mounir> lunch break

<spoussa> https://wiki.mozilla.org/WebAPI/DataStore

DataStore

mounir: one application owns a store
... others are allowed to be `readonly`, or `readwrite`
... the owner determines if a datastore can be readonly or readwrite
... the owner will be able to write
... the owner determines whether all other clients are readonly or all other clients are readwrite
... this is a work in progress
... you can have more than one store with a name
... e.g. Contacts, or Messaging
... a Skype application, a Facebook application
... each could have a Messages store
... an app could ask for access to all Messages stores, and assuming the user gives access to them, it gets access
... our goal is to give no constraints about the data
... the internal store of the data is a Sequence of elements with id's
... 0..n
... each element has an undefined structure
... we expect people to write to the store "correctly"
... and people to read the store "correctly"
... we expect the owner to write "correctly"
... and if clients are allowed to write, we expect them to write "correctly"
... specifying types doesn't work
... with JSON, you just write stuff
... it would be unintuitive to say "i want this to be a number, this to be an object"
... this would be very complex
... for messaging/contacts
... we'd need a way to sync
... when you get a store object, the object knows its revision
... an app can save its revision
... and when the app is reopened, it can ask for changes between its revision and current
... there will probably be a way to say "too many changes, start over"
... internally, we had issues w/ Messaging App
... one thing wanted to show unread count in the tree view
... and the name of the contact, and the icon
... the Messaging App was working like crap
... we need something that works fast
... the Messaging App gets the system store of Messaging and the system store of Contacts
... it will be backed with indexedDB
... the data will be copied
... but this guarantees fast access to the data
... and simple sync
... the manifest has a description

Josh_Soref: what if you want to show the description in various languages

mounir: the manifest will have localization bits

marcos: you can do it, but...
... we looked at localization, it gets tricky, and it looks a little silly
... the structure gets nested like 5 times

mounir: if you have a better idea, we're open to it
... it could be pretty ugly

marcos: there's a larger architectural question
... why are the descriptions there in the first place

mounir: we have descriptions because the security model
... take Facebook, it has contacts
... my app asks to get `contacts` data stores
... there are two contacts stores... system -- linked to contacts api
... and the facebook api
... but you need a ui that says do you want `mounir-app` to have access to Facebook contacts?

marcos: but i could use the wrong description

mounir: no, the system pulls this information
... for system stuff, we can write our own things
... for foobar, we can't handle it
... right now, our implementation
... will limit that to readonly stores
... if you have a writeable store (not readonly)
... and anyone can write it
... we'll ignore it
... it doesn't seem trivial to make a ui request for "do you want to allow writes to the facebook contacts"

Josh_Soref: why not have a function on the app which answers what is the description
... for a localization that i haven't installed yet, it might be better to let the app just run and get an answer for what the new locale description

mounir: you might not have the latest update, but you should have it quickly
... we'd love feedback for a web ecosystem

<Zakim> Josh_Soref, you wanted to ask how the client knows if there's another set of changes past the revision getChanges() gave

mounir: at startup, you get the datastore
... it's a reflection of the owner's store
... you know the new version id
... hopefully you saved the previous version id
... you ask for changes

Josh_Soref: but you first need to register for onchanges, or else it breaks

mounir: sure

spoussa: about the object you're storing
... that's different platform to platform?
... if firefoxOS defines something
... and someone else does something

mounir: the idea of the contacts api if we actually go to this
... the contacts api would be saying Contacts has
... Facebook would say
... We don't have a feature that says
... we don't have type verification
... tinker mentioned this in Italy
... we thought it was too complicated

zkis: where do you specify these objects

mounir: for things from the System
... here, owner will have a specific value, it could be "system" when it's from the system
... it could be a specification
... but if it's coming from a third party, we're expecting a third party to define it
... that's how the web works

zkis: do you have a special revision id for "i want all the data"?
... if i want all the data, how do i get it?

mounir: you just use getAll()

marcosc: why have another method?

mounir: getChanges is about a diff
... right now reivsionId is a uuid
... you don't want the full history of changes since the beginning of time
... after some time, you'll clean your history
... in that case, you don't want to say I've added all Ids
... it's the same

zkis: what does getAll() return?

mounir: getAll() was not specified yet
... it would be Promise<Object[]> getAll()
... if getChanges() says it can't give you changes anymore, you drop what you have and use getAll()

zkis: can you get an object to get the schema of the datastore?
... usually that's the case
... if you had an introspection api...
... that would be good enough
... you could do forEach on the object to enumerate the properties

mounir: we thought storing the schema was not a good idea
... i don't think it's very interesting to do
... let's say you have a schema that says "everything here has this stuff"?

zkis: between two revisions, if you have changed the datastructures

mounir: with this api, two objects can have different schemas

Josh_Soref: it's common to have union types in things

gmandyam: do you envision this api as a way to enumerate sim based contacts

[ laughter ]

mounir: this isn't really related
... this api reflects how things are stored
... if we want to enumerate sim based contacts
... that should be in the Contacts API
... and it's up to that API to decide how
... if the Contacts API says that the system store of contacts should include contacts from SIM card
... then it's up to the contacts api implementation
... i think this should be up to a SIM API

gmandyam: in the last F2F, we decided that Contacts covered SIM
... i just think it needs to be thought out more
... Second on Gallery. If this is meant to be a way to enumerate
... Media
... sicking had a comment about an application prepopulating the cache, which could be problematic

mounir: Gallery is a way to access pictures?

gmandyam: Pictures, Audio, Video, ...

mounir: this wouldn't be related to Filesystems

genelian: curious about using this datastore API to deal with extension database
... suppose system receives SMS message
... does the system directly save the SMS into the database
... and fire an onchange to the messenger app
... or should the system fire an onreceive event and let the Messaging app use the add method to add the message back to the database

mounir: the system should save the message
... for system, only the system would be allowed to write, not any apps

Dong-Young: why not use a shared version of indexedDB

[ laughter ]

mounir: that's a good question
... this was not my first idea
... it was to use indexedDB
... sicking was strongly against using indexedDB
... for reasons i can't remember exactly
... you'd have issues regarding synchronization
... even if you have one indexedDB thing
... we want clients to copy data
... and store data how they want and index it how they want
... if you have one indexedDB, then they're likely to try to access it in ways for which it wasn't optimized
... and it would be make synchronization more complex
... i'm not sure it would add much benefit
... if there's a reason to add benefit, we could think about it

Dong-Young: you're talking about synchronization when several applications share one database

mounir: at the first F2F, we had issues
... and internally we had issues
... if you're a Messaging App, and you want to find data
... the performance issues are mostly related to how you index the data
... to make everyone happy, you'd have to index on everything
... which would be horrible for performance

Dong-Young: do we need to mandate id to be an int?

mounir: i think it's simpler to have id be an int
... we could switch to something else
... an integer makes the implementation easier
... you can back that w/ a huge array
... a string would require a hashmap
... it seems like a bad idea, unless you have reasons

<Zakim> Josh_Soref, you wanted to ask how an app determines if the service is really the service it thinks it is and not something impersonating

mounir: we use origin

Josh_Soref: could you change it to be called origin?

mounir: we could

anssik: did you prototype this?

mounir: i did not
... someone at mozilla is implementing it
... someone from the Firefox OS UI team is working on it

anssik: did you stress test it

<mounir> DataStore API

anssik: who initiated this api?

mounir: me
... at the F2F last time, we finished early (?)
... sicking, tinker, genelian, and hsinyi and i thought about this

zkis: Messaging had Filters
... there were questions about efficiency
... and there was a discussion that this is a synchronization api
... it's pretty hard if it has to keep track of each revision
... if it's an opaque id

mounir: getChanges() can say "i don't have changes from that id -- you'll have to start over"

zkis: i proposed a timestamp

mounir: you could do that
... but i think it's better if it's an opaque string
... mozilla uses a uuid
... we don't want people to guess

timeless: there are privacy considerations, you don't want apps to know when there were changes

mounir: i don't want to assume all apis are only available for very signed apps
... otherwise it's too constrictive
... if you have a UC for it, but i don't see a reason

zkis: i have a revision id from this api
... i fetch changes since then
... if it isn't available, i get an error
... and i fetch all again?

mounir: yes.
... it's technically impossible to save all data
... it seems like the only sane behavior

zkis: you have multiple applications
... and you have to keep track of consumers?

mounir: no
... the client keeps track of what it saw last
... each application client will have the same datastore
... and it saves the revision id it last tracked when it closes
... and when it opens again, it checks that id against the current id
... and then it can sync
... you ca do it smoothly
... implementations don't need to know every id

zkis: can you do predictive scrolling?

mounir: the developer could do UI that refreshes smoothly

zkis: this solves only Sync

mounir: if your messaging is searching name+number
... you make your own indexedDB with indices on name+number

zkis: but, i fetch each one by one

mounir: no, you get it, and save it locally

zkis: so the data is duplicated N times (per application that uses a database)

mounir: this is the only way to solve the sync and indexing problem

zkis: so you make everyone do indexing?

mounir: if they want to

genelian: question about Race conditions
... suppose the central process has already removed a record
... and client hasn't yet called getChanges()
... and the client thinks the record is still valid
... what happens if the client calls update() or remove() and the record is no longer present?

mounir: i guess the Promise<> is rejected

genelian: the update/add will directly reject the operation?

mounir: not directly
... if you have multiple clients trying to update
... the central process will reject

genelian: the client app will get very confused
... because it doesn't know the reason

mounir: it will get a change event
... ah, you try to do something, not yet receive the change event
... but between your request and the fail, you'll get the change event
... the change event comes from the same entity
... so there should be order there
... hopefully it should just work

genelian: this api seems to provide a very good way for synchronizing
... and a fundamental api for dealing with a store
... is it possible to replace the whole contacts api?

Josh_Soref: +1

genelian: or do we still need a partial api?

mounir: i think the contacts api would limit itself to describe the system store
... there would be no more api for add/remove

genelian: sounds attactive

<Zakim> dsr, you wanted to ask about error handling on name clashes for data stores and to ask what Mozilla expects SysApps to do with the datastore proposal

<Zakim> dsr_, you wanted to ask about error handling on name clashes for data stores

dsr: provider provides datastore
... consumer consumes
... what if multiple applications provide the same name?

mounir: many applications can provide a store with a given name
... this is there to allow "Skype", "Facebook", and another contacts app, and "Google", and the internal one from the phone
... you call getDataStores("contacts")
... this solves an issue where Intel wants Contacts API from multiple spaces
... you have a GTalk

dsr: what do you expect us to do with this?

mounir: if the group is interested, we could start editing it, work on it, fix the details
... it's really a prototype
... we can use it to solve the problems from Contacts

dsr: just wondering if we have to extend the Charter

mounir: as i see it, it's there to solve Messaging and Contacts
... but i guess there are legal issues

zkis: last November, I think I had a Messaging API using a datastore of sicking's proposal
... how would you actually use it
... there were examples of SIM contacts
... you might want to store things by datasource (sim1, sim2, ...)
... i guess you can get rid of incoming events?

mounir: i don't know if you can get rid of incoming events, that would have to be discussed

zkis: datasources with different details/privacy
... you might not see everything

mounir: for this, sim1/sim2/sim3, the owner would be {magic-string-for-system}

zkis: which property would specify sim1?

mounir: the object get(n)...
... at any moment, if you want to know this you just work through your indexed database
... the system database only contains stuff from the system
... excluding Facebook, IRC, XMPP

zkis: in our case, that's the system
... this is not right, SMS could be a web service

mounir: then that would be the SMS app on the phone, and its datastore for sendsms.example.com

zkis: i think we need a source property

[ cross talk about sim/system/messages ]

mounir: if i have Hangouts
... even if it comes from the System
... it's actually hangouts.google.com

zkis: is only things defined in SysApps system?

mounir: yes

zkis: if you don't allow the owner property to own use the property to distinguish the source
... you're doing this based on an assumption that doesn't apply to all circumstances
... without understanding this, we can't say if we accept it
... it's missing a field

mounir: that's intentional
... i guess Intel isn't very enthusiastic about this api
... i'd like group feedback on it

lgombos: i'm not sure what you're asking for feedback on
... is the question "is this a good foundation for contacts+messaging"
... or "a good spec in general"

mounir: this could live anywhere, unless it's needed to solve our problems
... so, "does the group think this is a solution to try to solve contacts+messaging"

lgombos: i agree w/ zkis
... we can't decide if we don't go through an exercise to see if it works

mounir: as Chair, should we as a group try to work on this
... or should we discard it
... and try to solve it independently for Messaging/Contacts

lgombos: it's a fairly new spec
... we spent a lot of time trying to understand the proposal
... but we should spend some time looking at what this solves

mounir: you're asking what this solves for Contacts/Messaging
... it solves Syncing
... it solves Multiple provider

zkis: i think it solves things if we address datasource

marcosc: it solves the datasource issue
... we don't need 100 apis to do things over and over

lgombos: it inherently makes Contacts/Messaging more aligned

mounir: it reduces Contacts/Messaging to defining a Store
... no definition for Add(), Remove(), Find(), Filter()
... Messaging still needs Send()
... but we have to decide if it's a correct solution

lgombos: thanks for those
... i think we should continue and see how far we can go

marcosc: if i had an outside Mozilla hat on
... i'd like to see if it works for us
... i'm looking at it and going "it looks really interesting"
... but i'd really like to see if it works for Firefox OS

anssik: which other apps?

marcosc: Contacts, Messaging, Call Logs, Calendar
... a million cases that should have been covered by IndexedDB
... but there's another dataprovider

mounir: if you want to do Call Logging
... you could use this

anssik: you're very close to completion of the api?

mounir: i have to review patches

anssik: apps are done?

mounir: no
... we're fairly close to pushing to mozilla-central
... we have an app layer person experimenting with this
... trying to test it in their own repo
... i was hoping it'd be done earlier

anssik: sounds like after this F2F you'll have feedback

mounir: mozilla might use gaia.mozilla.org
... but there's no way to reach interoperability
... if tizen wants to ship w/ some default providers
... they'll have providers
... Firefox will have Facebook installed by default
... that app will have a Contacts app built in
... it will be a .facebook.com origin
... they don't have to rely on it being present

anssik: thanks
... you could make it more like a spec
... zkis you could try to look at it

mounir: unless marcosc looks at it, i can't commit anyone

marcosc: this proposal impacts a bunch of specs in phase one
... but it also reduces scope of a bunch of specs in phase one
... that's why it's important on the mozilla side to provide feedback asap
... and to address zkis 's concerns
... if we get that, i'd be interested in contributing

anssik: sounds like we'd want to push Contacts+Messaging to Phase 2 and replace them with this

marcosc: we no longer need them as DataSource
... my biggest concern is Cursor etc

chris: i have some concerns about Contacts
... when it comes to schema
... how do you specify it?

marcosc: it would be specified in JS as objects
... we have a non-normative thing in telephony
... we have a contacts object in the spec already

mounir: we'd just reuse the contacts object from the contacts api
... there it will be a JSONized thing

chris: there are several things this is trying to solve
... which could be solved in Contacts as well
... in Tizen, we have several sources
... and there's an origin, and readonly...

marcosc: Mozilla should report back w/ Implementation experience to the group

<anssik> +1 on marcosc

marcosc: so the group can make an informed decision

mounir: zkis's concern is multiple origin from the system
... which is not something we want to support
... we won't fix that

zkis: i think having this api
... is a good thing
... i think i'd know how to use this
... we could include it in the charter
... but we'd need to address it
... this could be done by issues

mounir: i don't believe this requires charter changes
... this does what Contacts/Messaging were trying to do
... IANAL
... this is doing Syncing
... which they were trying to do

dsr: it sounds like refactoring specifications
... so if we don't hear any objections, we presume we can do this
... are we putting DataStore into phase1 and Contacts into phase2?

mounir: on Thursday we'll consider new work items
... i'm ok w/ moving Messaging to Phase 2
... Contacts is a simple layer on the datastore
... it seems to be better to have a simple api on top of Datastore to drive it

zkis: i think we should keep all the phase 1 items
... this is a helper

mounir: i have no strong opinion, we should speak about it on Thursday

anssik: as long as we have resources to push forward
... i think we can keep them active
... if we have people to move them together in parallel, that's ok

mounir: +1
... with DataStore, we're not adding more work
... we're refactoring

chris: about revisionID in datastore
... when you access it twice in a row, it might return different values?

mounir: yes

chris: why not make it a method?

mounir: in battery api, if you ask the battery level twice, you might get different values
... there's a change event

chris: that id is an integer might be problematic
... vCard uses an integer

mounir: that's an internal implementation of the storage
... the vCard format would be the object
... the datastore associates an id with a vCard object
... the first id has nothing to do w/ the vCard object

chris: the datastore is a way to interact with a system backend?
... some contacts engines use a string id for their backend key

mounir: the id is just an autoincrement
... if you have an internal id, you have an internal id in the contacts
... if you want to expose gnome contacts, you'd integrate them
... and have them add and find a way to synchronize

chris: in Tizen, we have a Contacts API
... a web api in front of a Contacts backend
... may/may-not be the same one as in Gnome
... it doesn't seem like it's designed to expose a native backend

mounir: right
... it's designed to expose a contacts-api backend
... contacts api will define "some data"
... if for some reason your system is using some other backend
... you'll have to do the translation yourself

zkis: if you have a native interface
... and want to expose sync
... it's a shared database between applications
... per application v. per runtime copies

mounir: i didn't follow

chris: a datastore might be a native backend

{ 0: {vCardId: "10", name: "John Joe"} }

{ 1: {vCardId: "12", name: "Jane Smith"} }

+ lastModifiedFields on each

chris: why are you using a string key?

[ To have an Array backend ]

mounir: we're not trying to make implementations easy
... we're trying to make consumers lives easy
... there are a handful of implementations
... millions of developers
... i understand you need a layer between your native thing and your web thing

{ 2: {vCardId: "15", name: "Eric Lapp", lastModified: 912870374 }}

chris: we'd need two hashtables between string ids and integers
... it's annoying to implement

zkis: developers don't care if it's an integer or string
... DataStore exists because the other was too slow

[ you maintain a lastModified for your store, and a max count, and a mapping of uuid to lastModified ]

[ if uuid isn't found, you fail early on getChanges() ]

[ if uuid is found, you can just return all objects which have lastModified > lookedupLastModifiedByUUID ]

mounir: taking mozilla's wording, that mozilla should come back to the group w/ implementation feedback

dsr: do we need to clarify UCs?

mounir: yeah
... this is a discussion we had about Messaging last time
... iirc
... zkis was for allowing opaque ids
... there was a service thing
... that was a simId
... an int 0
... you wanted it to be a string for xmpp:irc:....
... for telephony it was the same
... using SIP client
... generally speaking, trying to do apis like that doesn't reach interop
... you'll get an app that checks the service id
... and that magic string will only work for Tizen
... you're using an api that's standardized in w3c

zkis: you can't say an id works in one place and anywhere else

mounir: once it's an opaque id, people can look at the id
... the id starts as a magic id in Tizen
... and someone will hard code it
... and app will do something
... this opaque string will be xmpp:1
... you'll definitely have developers using strings

zkis: apps in tizen don't care about the format of the id

mounir: apps in tizen might not care
... but third party apps will

zkis: but you don't care

Josh_Soref: we have experience with app authors sniffing UserAgent

mounir: you're saying the app will work on Tizen
... but it won't work elsewhere
... the idea is that if one implementation has the majority

zkis: we don't have this problem
... there's no fragmentation

mounir: there will be fragmentation

anssik: mounir, you have UCs
... you have them on your Wiki
... what's the way forward?

zkis: take Contacts/Messaging and see how they work with this API

anssik: exactly

<mounir> RESOLUTION: the group is going to work on Messaging, Telephony and Contacts on top of DataStore

[break]

Contacts API

<chris> mounir, pong

<genelian> http://contacts-manager-api.sysapps.org/

chris: we changed to Promises
... we added more Dictionaries
... we no longer have contacts in everything as a dictionary
... preferred is no longer a string, it's now a boolean

zkis: chris at the last F2F
... we discussed contact sources?
... could we have a way to access Facebook/Skype/etc.

chris: one possibility, but another is separate addressbooks

zkis: how do we access those datastores?

chris: with the current API, you could have getAddressBooks() and each has an origin
... this is the pattern used in Tizen
... in the root contact manager you can get a list of address books

zkis: i don't find that api

<kenneth_> https://developer.tizen.org/help/index.jsp?topic=%2Forg.tizen.web.device.apireference%2Ftizen%2Fcontact.html

mounir: can that be translated into different Datasources with different owner (origin) if we switch?

<zkis> yeah, but do we have multiple address books support in the W3C Contacts API?

chris: yes, this would solve the same problem

mounir: the owner would be the manifest uri

<mounir> facebook => http://facebook.com/manifest.json

<mounir> skype => http://skype.com/manifest.json

gmandyam: with a sim based contacts
... you're talking to a Secure Element
... when you enumerate the device
... -- the datastore API makes the assumption that the contacts are already on the device

mounir: for Firefox OS, we have a sim api, with a sim toolkit and there's a get contacts
... and from there you can save the contacts to the contacts in the device
... you can't write contacts to the sim
... we believe that's a UC from the 90s
... even getting seems outdated
... we think this is a sim api problem
... not a contacts problem

zkis: what if you want to keep the contacts api separate

mounir: my opinion is that we should have a sim api

zkis: we have a messaging api
... we wanted a datastore for sim
... just as us have a messaging api doesn't prevent us from storing messages
... we shouldn't be prevented from storing/exposing sim contacts

<gmandyam> My point was that the typical mobile OS prompts the user upon enumeration of SIM contacts to store the info in device memory - DataStore API has no such ability. Mounir responded that such functionality could be in a SIM API.

mounir: the reason i don't seem contacts on the device as the same as contacts on device
... as messages on sim as messages on device
... you're limited with contacts

zkis: messages on the sim card

mounir: oh, sms on the sim card? i don't think we support that

zkis: we'd just need one more property
... sim contacts, device facebook contacts

mounir: facebook UC is already solved by the owner attribute

zkis: if you solve FB, Skype, Google
... that doesn't mean you solve the problem

mounir: SIM contacts are part of the system, but not part of the system for real

zkis: what's part of the system depends on the platform

mounir: to a user, contacts on the device are part of the device
... on Android phone, you have Google Contacts and Device Contacts

zkis: the system thing is what messes up the whole idea

mounir: owner...

zkis: then we have a bad api

marcosc: i was going to ask what's next w/ the contacts api
... -> chris

chris: if i understood correctly, we wanted to see what it would look like w/ the datastore api

marcosc: correct
... you're ok with doing it?

chris: i'm ok w/ trying it out

marcosc: that's all i was wondering

Messaging API

<genelian> API

zkis: the last changes to Messaging were changing to using promises
... the issues are mostly editorial
... except for 79

<marcosc> https://github.com/sysapps/messaging/issues/79

s|https://github.com/sysapps/messaging/issues/79 consider using MessagingService|-> https://github.com/sysapps/messaging/issues/79 consider using MessagingService objects|

zkis: one approach is to make things simple for people just trying to send messages
... default service via defaultServiceId
... if we used a serviceObject, then the methods would be on the service itself
... and the service manager would just enumerate services
... at the last F2F
... mounir asked us to explorer this possibility

mounir: we spoke at Mozilla about having a default service

genelian: i don't think we have it
... we haven't tried to deal w/ multiple sim cards yet
... we do have a plan to be compatible w/ it
... our plan is quite similar to this proposal
... putting serviceId as a parameter of the send function
... to control which sim card to use
... i notice service related attributes
... for added/removed
... these things are also in the manager as well
... can these three attributes be put into an up-layer
... the messageManager which has both sms and mms
... why not put the service related attributes on the manager?

zkis: we had it that way
... but we were told to not have that much hierarchy

marcosc: from a JS dev perspective, it's pretty bad that it's

navigator.messaging.sms.send()

zkis: service objects would make this better

marcosc: yes
... or since they're static functions, putting them to smsmanager

zkis: so i can create a proposal by tomorrow

marcosc: yes

zkis: anything else?

genelian: we tried to delete 2000 messages
... with ids, we had to call deleteById separately
... and it took 30-40s
... if we can provide an array of id's
... it's better

zkis: i agree
... this was also originally an array
... this whole set of messages will change once messages integrate with Datastore

marcosc: it doesn't have delete(array[]), but we could add it

mounir: we can add it

genelian: it's worth adding

zkis: please create an issue

genelian: the array applies to deleteMessage/deleteConversation/markMessageRead/markConversationRead

zkis: does *Conversation still exist in Datastore?

Josh_Soref: probably not, since you'd be using *your* datastore instead of the main one

genelian: SmsManager.segmentInfo()
... whenever users type in characters into the text
... and something needs to enter text into the text
... and the UI wants to update the segmentCount
... or characters remaining
... this function is a synchronous function
... suppose we have text which is 5 characters
... the App needs to call it 5 times, one for each character
... this will block the process
... and make the user feels bad
... feeling the latency
... i'd suggest to make this function async

mounir: making this async
... you're typing in one process
... and you have to go to another process to get segment info
... you have ipc
... i'm assuming segment info is related to the sim
... can the JS do this math on its own or does it need something?

zkis: it needs something from the service
... my opinion/understanding is that you can implement it in a sync manner

mounir: the service lives in another process
... different from the app
... we ask the service a question involving IPC
... syncing the process

zkis: you should be able to cache that information
... i suspect it's just math
... but there could be an operator which has a service specific value
... i'll need to check the specs

hsinyi: about the service project proposal
... it looks like the very original one mozilla had
... discussing w/ sicking
... sicking suggested it's best to have a centralized sms received event
... it isn't symmetric that we have received in one place and send in another
... having one additional parameter to the sms api makes it easier

zkis: but if you try to send an sms with a stale token...

hsinyi: we have an api to get the services
... but proposals work
... but it's very hard to distinguish

zkis: i could create two specifications
... it'd be nice to have sicking comment
... hsinyi, please create issues about these things

TPAC

dsr: TPAC, Shenzhen, China, 11-15 November 2013
... could we do brainstorming on what topics?

anssik: is there overlap?

mounir: with WebApps
... we scheduled to not overlap w/ DAP
... but that resulted in overlapping w/ WebApps

dsr: would you like to see if i can make us not overlap w/ WebApps ?

mounir: that'd be good

dsr: Ian Jacobs sent an email to the chairs asking for info about what they'll cover @TPAC

mounir: we'll cover that on Thursday

Test Suites

marcosc: we'll have to build test suites at some point
... a lot of stuff happening @W3C wrt testing
... we'll hear a lot about testing @TPAC
... tobie langel went to w3c for a year on Testing the web platform
... work has been done on centralizing the web platform test suites
... at the w3c github
... there's testthewebforward
... testharness.js
... testharness.js can automate most webidl testing
... should we be allowed to go into LC/out of LC w/o a test suite
... that's something we need to decide as a group
... what role does testing play in our process as a WG?
... we can't exit CR w/o a test suite
... a lot of groups go into CR w/o a test suite
... testing is how you verify your spec
... going through line by line creating a test for every assertion
... it's probably done @LC
... a lot of the time, it's the editor who's writing the tests

<Marta> test suite @ LC +1

marcosc: in WebApps, there's a "Test Facilitator" who works on writing the test

mounir: it's better to have someone other than the editor writing the test

marcosc: it's tremendously difficult to get people to sign up for testing
... so i'm thankful to Marta for signing up for app:

mounir: can we get a Test Facilitator?
... maybe we can find a volunteer for the other specs
... what do people think?

<Marta> +1

marcosc: i'm in favor

Marta: i can do it, but not for every spec

<Marta> https://github.com/sysapps/testsuites/tree/gh-pages/app-URI

marcosc: kenneth_, who writes the tests?

kenneth_: webkit commiters write tests when they write the patch
... and tests for regression fixing

marcosc: we'll get some tests organically

<kenneth_> Marta, thanks

mounir: there's a huge gap between implementation and tests going to w3c

<Marta> kenneth_: np

mounir: we're trying to have someone dedicated to send tests to w3c
... i think having someone dedicated to making sure we have tests for every spec would be good
... which tests would you be interested in doing?

marcosc: task scheduler and possibly raw sockets

mounir: telephony?

Marta: App URI and Task Scheduler

<mounir> RESOLUTION: the group is going to have a test facilitator for every spec

<mounir> RESOLUTION: the specifications should have test being worked on starting LC, needed to go to CR

<mounir> RESOLUTION: marcosc is test facilitator for raw sockets

<mounir> RESOLUTION: Marta is test facilitator for app uri scheme

<mounir> RESOLUTION: marcosc and Marta are test facilitators for task scheduler

lgombos: i understand w3c is trying to harmonize testing
... that's great
... but that's basically for "drive by web"
... i don't know...
... we might need different things for sysapp testing

marcosc: tobie says it isn't
... we're supposed to get this for him too

lgombos: so we still need to write sysapps

mounir: i had a meeting w/ tobie
... about testing for messaging
... w/ testharness, we can only test the surface
... for messaging, do we want to test that an sms has been sent and received?

<zkis> you can have both levels

Josh_Soref: you could use GVoice and similar to receive SMS and check via http/imap/whatever

mounir: we could also use web driver

marcosc: when you go to CR, the Director looks at the Test Suite
... so we need something solid

End

mounir: let's call it a day, and we'll start tomorrow @9am

[ adjourned ]

- DRAFT -

SysApps Face-to-Face #2

27 Aug 2013

Attendees

Contents

Explanation of how to use meeting

Agenda

App URI

Raw Sockets

Task Scheduler

Raw sockets

DataStore

Contacts API

Messaging API

TPAC

Test Suites

End

Summary of Action Items

Scribe.perl diagnostic output