See also: IRC log
<anssik> Claes, zolkis, the same, passcode invalid
<anssik> wonsuk, ok, thanks!
<zolkis> not enough privileges to open the log at http://www.w3.org/2014/04/08-sysapps-irc
<mounir> scribe: mounir
marcosc_: since the last time I
saw you, since the manifest spec left this group, I analyzed
... looked at the conventional wisdom, things like authors, etc.
... even though Firefox OS had that kind of information, it was never used (same with Widgets)
... so we reduced the manifest spec to be only things actually used by runtimes instead of any metadata
... We want to make the manifest a tool to leverage webapps so they can be powerful, like installable
... (explains how permissions and signature would work with manifest and packaged apps)
marcosc_ is explaining some behaviour of start_url based on the example in manifest.sysapps.org
(discussion paused until we get the phone line connected)
gmandyam: can you share the data of the runtime usage of metadata you mentioned?
<anssik> dsr, thanks for fixing the conf :)
(phone is fixed)
(marcosc_ summarized what he was saying)
marcosc_: the big giant hole in
that is obviously offline, appcache is there but not
... but hopefully we have serviceworker
marcosc_: in the readme file, we have the v1 and v2 goals
(marcosc_ is listing the v2 goals)
(... from the link above)
marcosc_: what happens if you
load the manifest async regarding to csp policy? because you
have already loaded scripts
... the manifest is an unblocking resource that you load after the load event so if there is a CSP policy, given that the manifest is not part of the critical path, it might create a different behaviour at the second load
... service worker would have a similar problem
brad: so far the answer is that
the meta tag has to be loaded ahead
... we started with only headers to kind of avoid that kind of issues
anssik: I think that CSP1.1 not yet settled on the <meta> behavior
gmandyam: we had a pretty
conservative default security policy
... like no default inline
brad: the current spec says that
if you have a policy in the header, any meta policy is
... it might be an issue to work trough
marcosc_: we are hoping to past
this request feedback from the CSP folks soon on this
... updatable manifest, how to handle when the author update the manifest?
mounir: isn't that in the spec?
marcosc_: yes, but it's loose
mounir: it should be in v1 then?
... HTTP Link Header, this may never happen because there is no much interest but Jonas and Hixie like it
... inline manifest, this could be a future thing if people start doing that
<anssik> Feature Requests: https://github.com/w3c/manifest/issues?labels=Feature+Request&page=1&state=open
marcosc_: splash screens are problematics
mounir: we talked about that a few times and always realized it's not a good idea to do
marcosc_: make installable apps sharable...
opoto: what does sharable mean?
marcosc_: <didn't hear the
... there is then the question of how to do that with the standard track
... we could do a v1 then a v2 or a living document
... there is no decision yet and it's mostly process
opoto: there is no declarative permission requests
marcosc_: no, there is no real
need for that for the moment
... and we do not know what's the best approach for this
... we need to look into that
<marcosc_> mounir: the permission model of Sockets is complicated... and it's not yet solved in a non-packaged app. But we still don't know how to bring this to the Web.
<marcosc_> dsr: do we have time to talk about security stuff later in the agenda
<scribe> scribe: marcosc_
opoto: maybe the manifest is good way to addressing the permissioning problem by gathering things together.
marcosc_: we could go and look at how the permissioning model works in FxOS and in Chrome apps
mounir: I disagree that it's the same. Those things are not quite the Web - so it's a bit different.
brad: there is also iOS and
Android. Access control gadgets is work that microsoft did a
few years ago that could be relevant for the discussion.
... it's a different model to look at for contrast
dsr: I've been asked to write a white paper about this
<bhill2> actually: Windows Phone and iOS work more like the Access Control Gadget model vs. Android's manifest model
dsr: I have a few months to work on this
marcosc: it would be great if you could work with WebMob IG
<anssik> Dom's work on permissions: https://github.com/dontcallmedom/web-permissions-req/
<bhill2> Link to ACG work: http://research.microsoft.com/apps/pubs/?id=152495
mounir: Dom has also done some work on this
<mounir> s/tome work/some work/
Claes: I don't have much to add right now. However, Marcos talked about making manifest CORS compatible. But I dont' see that there
<mounir> scribe: mounir
marcosc_: you are right, anssik,
keneth and I talked of creating a spearate spec for packaged
apps to be CORS compatible
... you need an origin member in the manifest that doesn't specify http:// [the protocal] but just the domain
(marcosc explains how the origin value would be checked on the server)
marcosc_: we are using such
mechanism in firefox os for packaged apps
... i'm not volunteering to do it but it's doable
Claes: so it should be a separate spec?
marcosc_: yes, I can actually link to the extension point part of the spec
<anssik> [any packaged app specific features are out of scope for the core spec, should use the extension point]
marcosc_: any spec can use that
extension point to hook in new features
... it should be little work and pretty trivial
Claes: we can have a look at that and see how that goes based on the needs we have
marcosc_: take a look at firefox os manifest
marcosc_: it is tried and tested and used in the wild
Claes: why have a separate specification?
marcosc_: it doesn't make sense
for web pages
... it is something that only packaged applications would use
<marcosc_> Claes: we will look at that
marcosc_: bug related to servige worker ^
marcosc_: datastore defines its own model
jungkees: we are working on
service worker, it is now in the charter of the webapps
... the actual work is made on GitHub
... Mozilla, Google and Samsung are working on this
... We are done with the v1 features
jungkees: the spec is still being
... a servece worker can fetch the resources
jungkees is describing the service worker specification/features to the group
genelian_: the goal of the task
scheduler is to open the app when it is no longer running
... how would service worker do that?
jungkees describes how task scheduler works
jungkees: the idea is to launch a
service worker and run the script
... we don't need to open any tab
... within the worker code, the developer can create a notification, for example
cdumez: so every app using task scheduler will have to create a service worker?
jungkees explains how a service worker gets woken up by an event after the developer registered for it
jungkees shows example from the service worker GitHub repository
<wonsuk> Push integration example with ServiceWorker: https://github.com/slightlyoff/ServiceWorker/issues/177
<discussions around service worker examples shown in the room>
opoto: when a web page register a
service worker, is there a spec explaining how this is
... because this is a service and it is persistent
jungkees: for the initial version, to install the service worker, we should do https only
opoto: it's good to require https
but we should inform the user about what's hapenning
... and about the registration, is there any requirement about the display?
wonsuk: there would be a problem if the web application uses memory uses without the user permission
<Zakim> dsr, you wanted to ask which companies are implementing ServiceWorker and whether this includes mobile devices?
dsr: what companies are implementing service worker? what about mobile device?
jungkees: Mozilla and Google are
... it should be implemented in 2-3 months for a beta version
mounir: on Mobile, the problem is more complicated than desktop because waking up the service would take memory and cpu...
<Zakim> anssik, you wanted to note Chrome Canary has an experimental UI for unregistering SWs meant for debugging purposes only: chrome://serviceworker-internals/
anssik: there is a UI for
... is Google working on a better UI?
mounir: don't know
anssik: developers as well as users might want to be in control of that UI
jungkees: we might want to talk about service worker integration with manifest
mounir: we should keep manifest/service worker integration to the webapps meeting so we don't repeat ourselves
<anssik> http://status.modern.ie/ says Service Workers is Under Consideration
mounir: we might want to move task sceduler to webapps because it will reach a broader audience
<Zakim> anssik, you wanted to ask about the plan for extension points in the SW spec for future events, if not deemed out of scope for this session
anssik: i remember talking to
alex about extensions point for the spec
... is there an issue I should follow to track the progress on this?
jungkees: you are talking of application lifecycle events?
jungkees: let's talk about that offline
anssik: it would be good for people that want to build on top of SW
<dsr> .... coffee break for 15 minutes ....
<dsr> scribe: dsr
<scribe> scribenick: dsr
Opoto: the web security model
today is mostly based upon the document origin, but we now need
to consider system applications.
... There could be access to sensitive data including credential stores. We need some form of access control for sensitive APIs, and to identify that an application can be trusted. This is missing today.
<terri> dsr: is that really the zakim code? I'm not able to join.
Wonsuk: we need to use existing
mechanisms or we need to look for new ways based upon the
principles of the Web
... in my opinion package signing would not be good, as it doesn't work well with hyperlinking
... hosted apps gets you the latest version, but this isn't the case for packaged apps.
... we can have security mechanisms for packaged and hosted apps, but my focus is on hosted apps, and to cover packaged apps as corner cases.
... Vendors are using their own signed package schemes
opoto: we should try to find a common security/trust model for packaged and hosted apps.
Mounir: this has proven to be hard in practice, you can't trust websites much
Marcos: I am not sure agree. It
is a very challenging problem. The web security model is deeply
embedded into the browser code, so we need to align with the
... I am optimistic that we will eventually be able to address, but it will take more than the people in this room.
opoto: do we agree that there is a need for this?
Marcos: absolutely, yes!
... The Node community are also interested in this. However, there are huge UX challenges.
... normal users won't want to see technical permission dialogs
... people are using iOS and Android and the World hasn't collapsed.
Mournir: there is a difference due to the ease of following a link. There isn't the same curated app store model.
opoto: do you see this being done in SysApps?
Marcos: we need to deal with this
in a broader community. The HTML WG is still some way to go
before addressing this.
... current focus is on extending the markup, HTML6 primarily about web components, and further work on expanding scope of CSS.
... we don't have all of the major players here in SysApps. Previous efforts e.g. Bondi didn't work out as they didn't involve sufficient range of stakeholders.
Giri: it is about how apps are distributed and it has proven hard to reconcile different approaches.
Marcos: the packaged app approach hasn't worked out, so we should focus more on hosted apps and approach matters from the web security model perspective and try to embrace packaged apps as there is a clear demand for them.
<gmandyam> Slight modification: I think BONDI didn't solve the security/permission/signing problem was because the platforms that existed at the time were so different i ntheir approaches that it was difficult to commonalize.
Marcos talks about phonegap experience.
Dave: automotive domain where web apps are starting to appear in cars, these folks are seeking guidance
Marcos: suggest looking at best
commercial experience and experiment, but trying to experiment
in a standards body isn't a recipe for success
... there are lots of things you can look at e.g. widgets
Wonsuk: I had a private meeting
last week with Mozilla and Google, and they are also interested
in moving this forward.
... What things can we progress within the existing web security model (same origin), and what things would break that e.g. raw sockets.
... We should clarify which APIs can fit within the existing model
... We need to go step by step
lgombos: it is likely that many of the SysApps APIs will break the same origin model
Mounir: perhaps all of them except task scheduler
ServiceWorker is interesting in how it relates to the security model
Jungkee: maybe we can try to come up with a solution for APIs that break the sandbox model
Wonsuk: I attended the W3C TAG meeting last week, one idea that came up was to use the website's reputation
Marcos: Alex has been throwing around the idea that if a site meets sufficient criteria, e.g. uses SSL, has been used so many times etc. then it is more likely to be trusted.
Mounir: some APIs should be
limited to https, e.g. geolocation
... for apps that include a manifest, that in its own merits some trust
... the push API is not about sensitive data
jinsong: my understanding is that
there is 2 levels of security for the web -- hosted and
... I have been learning about work relating to this in China. They want to protect user's privacy/security. They didn't accept the use of pop-ups
... They have the notion of certified apps, and they require explicit user confirmation for sensitive APIs e.g, access to camera or microphone.
... They also need a means to allow users to switch on and off app permissions.
Marcos: iOS allows you to alter privacy settings in an app specific way.
opoto: this relies on users to control security which isn't very effective for everyone
Marcos: on iOS this can be many levels deep in the settings
opto: it is also unclear how changing the settings effect the application
Dave: maybe there is a market for 3rd party tools for monitoring and managing your security as a way to get around individual users level of technical savvy
<Zakim> anssik, you wanted to note https://developer.mozilla.org/en/docs/The_Places_frecency_algorithm et al.
Jinsong: there are indeed tools for monitoring what apps are doing, but there is a need for such tools to update the security settings for apps.
<anssik> another interesting research-y area is http://en.wikipedia.org/wiki/Reputation_system
Anssi: I've droped a link to work that looks at the frecency at which you've visited a site, and it would be interesting to combine with reputation. This still feels like a research areas for innovation before we start on standardization.
<anssik> The word "frecency" itself is a combination of the words "frequency" and "recency."
Dave: is there any work on being able to sign hosted apps?
Marcos: for FirefoxOS you can only sign packaged apps
<anssik> [ The frecency algorithm https://developer.mozilla.org/en/docs/The_Places_frecency_algorithm ]
Wonsuk: hosted apps keep changing which creates challenges for signing
Dave: you can make signing dynamic as a work around when needed
Maros: Anders R. has some ideas
<lgombos> slightly related work - http://w3c.github.io/webappsec/specs/subresourceintegrity/
Brad: scaling issues, e.g. with certificate expiry, competing approaches, but these generally haven't mapped well into the Web space.
Marco talks about the experience during work on the widget spec
<jungkees> Packaging on the web discussed last week: http://oksoclap.com/p/packaging-on-the-web
opoto: most of the sysapps APIs require a solution so we are faced with a real challenge!
Marcos: yes, Adam B. insisted we
work on the security model for SysApps, but we have not lived
up to that
... we break for lunch and will resume at 1pm PST ...
<Github> [13tcp-udp-sockets] 15ClaesNilsson pushed 3 new commits to 06gh-pages: 02http://git.io/QS_55g
<Github> 13tcp-udp-sockets/06gh-pages 14d1d6956 15Claes Nilsson: interface UDPSocket rewritten to be based on Streams API
<Github> 13tcp-udp-sockets/06gh-pages 140600e85 15Claes Nilsson: Updates according to comments bt Domenic.
<Github> 13tcp-udp-sockets/06gh-pages 14690a29c 15Claes Nilsson: Merge pull request #64 from ClaesNilsson/gh-pages...
<Github> [13tcp-udp-sockets] 15ClaesNilsson opened pull request #65: Corrections (06gh-pages...06gh-pages) 02http://git.io/Bk2ykQ
<Github> [13tcp-udp-sockets] 15ClaesNilsson closed pull request #65: Corrections (06gh-pages...06gh-pages) 02http://git.io/Bk2ykQ
<Github> [13tcp-udp-sockets] 15ClaesNilsson pushed 2 new commits to 06gh-pages: 02http://git.io/_8Dd2w
<Github> 13tcp-udp-sockets/06gh-pages 14834186c 15Claes Nilsson: Corrections
<Github> 13tcp-udp-sockets/06gh-pages 14afcbf90 15Claes Nilsson: Merge pull request #65 from ClaesNilsson/gh-pages...
<marcosc> Claes: I sent the presentation to the list
<marcosc> [Claes will walk through his presentations ... slide link forthcoming ]
<mounir> scribe: mounir
<scribe> scribenick: mounir
Claes is going trough the slides
Claes: the api name is "TCP and
UDP Socket API" because "Raw Sockets" wasn't very clear
... the API is being re-written to be based on Streams API
... the motivation is to handle the complexity of sending, receiving, buffering the backpressure
... there are two Streams API being aligned
... the rebasing work is done on top of WHATWG API instead of W3C Streams API
marcosc: the WHATWG Streams is
going to be the primitive Streams API for the platform
... which is going to be moved te ECMAScript
... the W3C spec is going to be on top of that
... this is a great primitive for a ton of API using Streams
Claes: what's the Streams
... it provides an interface for creating, composing and consuming streams of data
Claes read the slides
s/Cleas read /Claes reads /
<terri> I can hear Claes on the bridge fine, so it might be on your end
<marcosc> Claes, I think it might be us
<marcosc> Claes: we are dialing in again
Claes continues reading the slides after some phone connectivity issues
Claes: slide 11 is the previous
version that is not Stream based
... if we look at the next slide, we have two attributes, one is ReadableStream and the other one is WritableStream
Claes continues reading the slides
Claes: the example in slides 16
is using the new TCP interface based on Streams
... input is the writable Stream
... so you are write a text and then if the promise return resolve, you wait for the readable side (output.wait())
... then you receive data
... and read out the data
cdumez: why are we calling the method socketClose() and socketHalfClose()?
Claes: I have actually changed
... 10 mins ago
opoto: so halfClose() is for closing the input?
Claes: it's for closing the writable side indeed
opoto: shouldn't the close() be on the writable stream interface?
Claes: input.close() is a
... ppl familiar with TCP Socket are familiar with halfClose() term
gmandyam: is server socket stable or do you plan similar changes on that?
marcosc: what are your plans from here wrt this?
Claes: finish the specification
and have a prototype implementation
... I can't promise that I will have time to do the implementation
... but I hope that it could be done by someone else
... any voluntary resource would be appreciated
marcosc: as a reference it might be possible to wrap the Firefox OS API
anssik: we have some persons interested in this and could write an experimental implementation
marcosc: you go to the whatwg streams repo, you can find a reference implementation there
marcosc is looking for a link
<Zakim> anssik, you wanted to ask whether one could wrap the previous iteration of the API?
Claes: we should see if it could
be implemented on top of Firefox OS TCP API
... I will check some alternatives and come back on that
mounir: implementation status?
anssik: we are interested but we implement the previous one
marcosc: we are watching and seeing
lgombos: what's the story regarding permission for TCP/UDP?
Claes: this relates to the
discussion we had before lunch
... it has to be a store security model, we can't do a simple security model
... it opens up too much stuff
... we have to relate to the discussion for security/privacy
lgombos: are you saying that it
belongs to the spec but we can't spec it out?
... or do you mean that it's outside of the specification?
Claes: it's a sensitive api like other apis
mounir: to answer lgombos' question, I think this is bigger than the spec
jungkees: I think lgombos' question was more that we currently have a specification but no permission model for it, so what should we do with it?
<wonsuk> slide: https://mail-attachment.googleusercontent.com/attachment/u/0/?ui=2&ik=53293ca563&view=att&th=1454160492b8137f&attid=0.1&disp=inline&safe=1&zw&saduie=AG9B_P_9ZyqSId_uZvO2K-Bes8iX&sadet=1396990101753&sads=g8k7O62q8uIis8Xvs13F4IwtVHo
Claes reads the slides
Claes: so that's the proposal, any comment?
mounir: I don't think we should work on that
marcosc: I will send my comments
to the list and give my rational on that
... on firefox os there is an alternative screen homescreen
<scribe> scribe: marcosc
<scribe> scribenick: marcosc
mounir: I also wanted to point out that this API is very closly tied to the permission and security model. So moving it forward might complicate things further with regards security. The APIs are very very different and they have very limited interop. It might be too optimistic/early to try to standardize this.
lgombos: is the entire set of use cases related to security - or can there be a subset that is more limited that we all have agreement on?
Claes: maybe that would be good
mounir: I don't know if we can find such a baseline
<anssik> we had an API in the Manifest to "install" an app, but dropped it based on feedback
mounir: there is complexity with regards to the kinds of apps your can launch (priveliged vs hosted, etc.)
lgombos: the thing that we hate on the web is getting a bunch of install buttons for native apps
mounir: as anssik said, we had an
API, but now we dropped it because it's better to let the
browser handle it.
... I'm not saying this is the final thing, but we should experiment in the browsers first
lgombos: the initial intent of this API was to allow people to create a store, but I agree that that is very ambitious
<mounir> scribe: marcosc
<mounir> scribenick: marcosc
<mounir> scribe: mounir
<scribe> scribenick: mounir
marcosc: I personally wouldn't
want to have us work on this
... like Mounir said earlier, it goes back to the manifest
... that could be used as a start, using that metadata
... to build a store site and share half the metadata with
... the store and the application itself
mounir and marcosc chats about things and how the web could be better
marcosc: it's complicated
... that's my perspective
... I'm not in favour in working on this or bringing this to the group
RESOLUTION: the group believes it is not ready to start working on that deliverable
break - 10 mins - 14:20
cdumez: let's review the
... an application can only access its own scheduled tasks
... a task id must be unique within its origin
... a scheduled task must be restorted at restart
... a scheduled task must wake the system
... a scheduled task that was supposed to run when the system was shutdown must run at startup
mounir: I think we sholud say that if you miss a task you should run it ASAP
<zolkis> i.e. instead of "must" use "should"?
cdumez continues reading the list of requirements
cdumez: but there is uninstalled
... which doesn't really exist anymore
<zolkis> say if you leave the phone off for two weeks, then you switch on, and get all missed daily alarms?
marcosc: what owns the tasks? what is an application? should that be the service worker? the origin? the document?
jungkees: we might want to use the service worker scope
marcosc: we could go further and make this only apply in the context of service worker
cdumez: but we should be able to register from the page
marcosc: but then you need to pass a service worker when you register the task
cdumez: I didn't understand that was needed
genelian: so the timezone issue is covered by item #6, right?
cdumez: timezone change is indeed
<Zakim> anssik, you wanted to ask about plans to expose TaskScheduler in ServiceWorkerGlobalScope
anssik: it seems that we reach a consensus here
marcosc: we need to ask the service worker people
<scribe> ACTION: cdumez will change the requirements to specify that a missing task must be restored (regardless of why it was missed) [recorded in http://www.w3.org/2014/04/08-sysapps-minutes.html#action01]
<scribe> ACTION: cdumez will investigate how to correctly plug the API to Service Worker - probably using the Thursday session [recorded in http://www.w3.org/2014/04/08-sysapps-minutes.html#action02]
discussions about service worker and how it works
<scribe> ACTION: make the task scheduler task not aware of application install/uninstall - use SW unregistration instead of uninstall [recorded in http://www.w3.org/2014/04/08-sysapps-minutes.html#action03]
mounir: is Mozilla implementing the spec?
genelian: no, we are still using our old version
cdumez: there is an open bug about adding a privacy and security issue section
marcosc: I believe Jonas sent an email about that a year ago
<scribe> ACTION: cdumez should write a privacy and security issues [recorded in http://www.w3.org/2014/04/08-sysapps-minutes.html#action04]
marcosc makes odd sounds
marcosc: after not looking at
this for a couple of months, I read it again
... and layered it on top of fetch
marcosc: the result of doing that
is that the spec reduced quite a lot
... as hoped
... there is like no spec now, it's like five sentences
... all I need to do is to handle the scheme
... the URL spec handles all the parsing
... and the fetch spec all the parsing
... I sent a pull request to Anne to plug 'app' in the fetch spec
... anne might tell me to take a hike
genelian: aren't you guys in the same team?
marcosc: literally, yes
opoto: regarding the instance identifier, you said that it could be provided by the developer, do you have any more information?
marcosc: in the manifest, we spake about the 'origin' thing, in that case we would use that component
brad: does that mean that I can access an app's resources if I set 'origin'?
mounir: no because you will be http vs app, so the domain/sub-domain would be the same but not the protocal wrt origin
brad: it would be interesting to discuss that in the context of subresourceintegrity from webappssec
marcosc: that's the current status, still waiting for anne's answer
gmandyam: what would be the
... would the entire spec move in fetch?
marcosc: no, just a part of it
mounir: implementation status?
marcosc: firefox os implements
... not exactly the same but could be changed to match
... if there is interest
lgombos: and crosswalk too
<anssik> I can confirm Crosswalk implements the spec
marcosc: it would be interested to see how it's done in crosswalk
<Zakim> anssik, you wanted to ask whether there is a test suite (planned) for the Fetch spec?
anssik: is there a test suite for the fetch spec?
marcosc: I imagine that there
will be but fetch just captures what the web currently
... in term of test suite, there will be an actual api for fetch
... Look at fetch as a meta spec that describes the behaviour of the web
... however, there is a test suite for the app uri that Marta has build - she did a very nice job there
<anssik> we can look at that if there's something to improve
marcosc: that spec is sitting on
the w3c web platform test repo waiting review
... and I've been too lazy to review it
<anssik> ok, we're already looking at that then :)
<Zakim> mounir, you wanted to ask what's the added value of that spec
mounir: what's the added value of that spec?
marcosc: given that the platform
does not define how to deal with local resources
... given the security and privacy issues of using the file://
... (like iOS will show the username)
... we avoid some of those issues
... we also get the added benefit of using the web platform technology
... without that you can't use xhr
... (because of missing origin)
mounir: this is the value of having a scheme, but not an interoperable one
marcosc: the hole purpose is having the same behaviour, not the name
genelian: I just recall why we
kept the respect-timezone part of the api
... it seems that your api only need the absolute change
... how can you get the new timezone?
<scribe> ACTION: cdumez will look at how native platforms handle the alarms wrt timezone [recorded in http://www.w3.org/2014/04/08-sysapps-minutes.html#action05]
<scribe> ACTION: mounir will look at how Android handle the alarm clock features like week-ends and week days and what API is used for alarms [recorded in http://www.w3.org/2014/04/08-sysapps-minutes.html#action06]
<dsr> Android's alarm clock distinguishes weekends from weekdays, what do they rely on to achieve that?
we are done for today
thank you all
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/is <inaudible>/not yet settled on the <meta> behavior/ Succeeded: s/tome/some/ FAILED: s/tome work/some work/ Succeeded: s/2-3/2-3 months/ Succeeded: s/developers/developers as well as users/ Succeeded: s/the user knowledge/the user permission/ Succeeded: s/frequency/frecency/ Succeeded: s/which is/... which is/ FAILED: s/Cleas read /Claes reads / Succeeded: s/Firefox OS API as a reference/Firefox OS API/ Succeeded: s/a reference API/an experimental implementation/ Succeeded: s/make the system/wake the system/ Succeeded: s/Topci/Topic/ Found Scribe: mounir Inferring ScribeNick: mounir Found Scribe: marcosc_ Inferring ScribeNick: marcosc_ Found Scribe: mounir Inferring ScribeNick: mounir Found Scribe: dsr Inferring ScribeNick: dsr Found ScribeNick: dsr Found Scribe: mounir Inferring ScribeNick: mounir Found ScribeNick: mounir Found Scribe: marcosc Found ScribeNick: marcosc Found Scribe: marcosc Found ScribeNick: marcosc Found Scribe: mounir Inferring ScribeNick: mounir WARNING: No scribe lines found matching previous ScribeNick pattern: <marcosc> ... Found ScribeNick: mounir Scribes: mounir, marcosc_, dsr, marcosc ScribeNicks: mounir, marcosc_, dsr, marcosc Present: Wonsuk_Lee Jungkee_Song Zoltan_Kis Claes_Nilsson Bin_Hu Mounir_Lamouri marcosc Olivier_Potonniee Anssi_Kostiainen Dave Anssi Zoltan Claes Gene_Lian Got date from IRC log name: 08 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/08-sysapps-minutes.html People with action items: cdumez how investigate make mounir will[End of scribe.perl diagnostic output]