RE: [apis] Gap analysis for Indexed Database API

Hi Bin I agree with your proposal :). Sorry I didn't managed to join the Telco today but next week I will report about my task "Service Worker Gap Analysis". Here are my comments to the Service Worker document on github (https://github.com/slightlyoff/ServiceWorker)  :

-          ServiceWorker provides a more flexible way to manage the App cache

-          The  Application Cache API is more static, all rules are listed in single manifest file.

-          ServiceWorker proposes to control the App cache using a script (Javascript file) which will be installed the first time the web application is launched

-          The script runs in the background using the W3C WebWorker and register a fetch listener to intercept all data loaded from the server. each App provider can implement the script containing the logic how to manage the cache.

-           ServiceWorker proposes also to use IndexedDB API for the cache. Video, Images can be stored as a Blob.
There is no API spec for now I am not sure if we can consider this proposal in our gap analysis. What do you think?

Best regards,
Louay


From: HU, BIN [mailto:bh526r@att.com]
Sent: Mittwoch, 4. Dezember 2013 16:00
To: Bassbouss, Louay; public-web-and-tv
Subject: RE: [apis] Gap analysis for Indexed Database API

Many thanks to Louay for the updates.

I agree to the proposal of REQ 20 and REQ 24 to change to "Y".

With regard to REQ 3, REQ 4, REQ 6 and REQ 14, I suggest to remove the "?" and leave them blank. This is because the essence of the requirements is not necessarily related to offline storage.

Thanks
Bin

From: Bassbouss, Louay [mailto:louay.bassbouss@fokus.fraunhofer.de]
Sent: Wednesday, December 04, 2013 1:39 AM
To: public-web-and-tv
Subject: RE: [apis] Gap analysis for Indexed Database API


Dear all,



I also updated the Indexed Database API column after our discussion in the Telco last week. Below are my updates (comments):

- REQ3 - Service Aggregation Mechanism: ? not changed. Not clear from the REQ description if there is a need to store offline data.

- REQ4 - Service Synchronisation Mechanism: ? not changed. Not clear from the REQ description if there is a need to store offline data.

- REQ6 -  Device Authentication Mechanism: ? not changed. Same reason as for "Payment Mechanism".

- REQ14 - Payment Mechanism: ? not changed. Not clear from the REQ description if there is a need to store offline data (tokens, keys, etc.). During the phone call last week I said that we can use the WebCrypto API instead (reason was secure storage of payment data). This is not correct  since the WebCrypto API is only about "performing basic cryptographic operations in web applications such as hashing, signature generation and verification, and encryption and decryption" but not for Storage. A combination of both APIs (Indexed DB and  WebCrypto) is then relevant for this requirement if there is a need to store offline data.

- REQ 20 - content download: ? turned to Y: File API will be used to store the payload of the content, Indexed Database API maybe for Meta information with a link to the stored file since Indexed Database API supports File as value type. Payload can be also stored as a Blob in the Database without the need for a File System and File API but I don´t think that this is suitable for large amount of content. It fits more for storing small images like profile pic etc.

- REQ 24 - content recording while watching: ? turned to Y: same as for content download.



TODO for editors of REQ3, REQ4, REQ6 and REQ14: Please check if there is a need to store offline content. If yes we can turn ?  to Y. If no we can remove the ?.



Best regards,

Louay



-----Original Message-----

From: Daniel Davis [mailto:ddavis@w3.org]

Sent: Mittwoch, 4. Dezember 2013 06:59

To: public-web-and-tv

Subject: [apis] Gap analysis for Network Service Discovery



Hi all,



I've updated the requirements spreadsheet [1] to remove the question marks from the NSD column. Actually, I turned all of them to red crosses for the following reasons:



6. Device Authentication Mechanism



Authentication is not in scope for the NSD spec. This is probably better handled with Web Crypto or others.



7. Local Access Control



As discussed at TPAC, the requirement itself needs more refinement before determining how in-scope this is.



17. Tuner Control



Tuner Control, or something similar, is likely to need its own spec or API so is not part of NSD. Moving this forward is being discussed separately.



By the way, I won't be in the call today but hopefully this can resolve the outstanding work for NSD.



Thanks,

Daniel



[1]

https://docs.google.com/spreadsheet/ccc?key=0AvACjV6qSvmxdEctdjYwa2JOalZLOG10elE1LVRZNlE&richtext=true#gid=1