W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2013

Re: [admin] Relationship of DAP and SysApps deliverables

From: <Frederick.Hirsch@nokia.com>
Date: Tue, 19 Feb 2013 22:29:36 +0000
To: <wonsuk11.lee@samsung.com>
CC: <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>, <w3c@adambarth.com>, <dsr@w3.org>, <dom@w3.org>, <cpgs@samsung.com>
Message-ID: <1CB2E0B458B211478C85E11A404A2B2701925BB1@008-AM1MPN1-035.mgdnok.nokia.com>
> 2. Network Interface API
>
> SysApps Phase 2 deliverable, may build on DAP deliverable
>
> DAP: Network Information API, under current development,
> https://dvcs.w3.org/hg/dap/raw-file/default/network-api/Overview.html


Sys Apps WG charter has below description for Network Interface API. This description already considered Network Interface API in DAP WG. So Sys Apps WG probably should change the name of the spec for removing confusion, but content of the spec would not be overlapped with Network Interface API of DAP WG.

An API to manipulate network interfaces (mobile, WiFi, etc.), such as listing available networks, current strength, etc., as well as configuring and enabling them. It may build atop the simpler network information API that Device APIs is working on. Potential uses include offloading connections from mobile networks to WiFi, enabling high priority mobile data connections and control of other network features.


Perhaps SysApps API should be called  "Network Interface Management API" ?

regards, Frederick

Frederick Hirsch
Nokia



On Feb 14, 2013, at 10:40 AM, ext Wonsuk Lee wrote:

Hi. Frederick.
Thanks for great summary!


> -----Original Message-----
> From: Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com> [mailto:Frederick.Hirsch@nokia.com]
> Sent: Thursday, February 07, 2013 11:58 PM
> To: public-device-apis@w3.org<mailto:public-device-apis@w3.org>
> Cc: Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com>; wonsuk11.lee@samsung.com<mailto:wonsuk11.lee@samsung.com>;
> w3c@adambarth.com<mailto:w3c@adambarth.com>; dsr@w3.org<mailto:dsr@w3.org>; dom@w3.org<mailto:dom@w3.org>
> Subject: [admin] Relationship of DAP and SysApps deliverables
>
> [Sending to DAP mail list and chairs/team, as I'm not a member of
> SysApps]
>
> There is some overlap of the Device APIs WG  (DAP) [1]  and System
> Applications WG (SysApps) [2] deliverables which may require some
> coordination.
>
> Specifically, both DAP and SysApps have the following work items
> (using SysApps terminology)
>
> 1. Contacts
>
> SysApps Phase 1 deliverable, (editors draft
> http://sysapps.github.com/sysapps/proposals/Contacts/Contacts.html )
>
> DAP : "Contacts API",
> http://www.w3.org/TR/2011/WD-contacts-api-20110616/

> and "Pick Contacts Intent" ,
> http://www.w3.org/TR/2012/WD-contacts-api-

> 20120712/

For Contacts, in my understanding, DAP is trying to develop the contacts spec based on Web Intents (instead of Contact APIs) because of privacy and security issue. So I would like to propose to separate the R&R of DAP WG and Sys Apps WG as Sys Apps WG has a role for contacts APIs and DAP WG has a role for contact spec based on Web Intents(or Web Activity).


> 2. Network Interface API
>
> SysApps Phase 2 deliverable, may build on DAP deliverable
>
> DAP: Network Information API, under current development,
> https://dvcs.w3.org/hg/dap/raw-file/default/network-api/Overview.html


Sys Apps WG charter has below description for Network Interface API. This description already considered Network Interface API in DAP WG. So Sys Apps WG probably should change the name of the spec for removing confusion, but content of the spec would not be overlapped with Network Interface API of DAP WG.

An API to manipulate network interfaces (mobile, WiFi, etc.), such as listing available networks, current strength, etc., as well as configuring and enabling them. It may build atop the simpler network information API that Device APIs is working on. Potential uses include offloading connections from mobile networks to WiFi, enabling high priority mobile data connections and control of other network features.

> -----
>
> DAP also has items that have been 'shelved' [3] which means DAP
> currently has old drafts that are no longer being progressed, but
> which might be picked up again
>
> 3. Messaging API
>
> SysApps Phase 1 deliverable (editors draft
> http://sysapps.github.com/sysapps/proposals/Messaging/Messaging.html )
>
> DAP - currently "shelved"  , http://dev.w3.org/2009/dap/messaging/


I am not sure but I think this might has security and privacy issues. For example, crazy web app could send an SMS/MMS/email to somewhere else without user permission. So I think Sys Apps WG might be better location for making this spec. What do you think?


> 4. Calendar
>
> SysApps Phase 2 deliverable
>
> DAP - currently "shelved", http://dev.w3.org/2009/dap/calendar/

>
> 5. Device Capabilities
>
> SysApps Phase 2 deliverable
>
> DAP "System Information API" - shelved,
> http://dev.w3.org/2009/dap/system-

> info/
>
> -----
>
> In addition, in passing I note the following might have some relation
> to Web Crypto
>
> 6. Secure Elements API
>
> SysApps Phase 2 deliverable.  No corresponding DAP deliverable, but
> how does this relate  to the Web Crypto WG [4] deliverables?

Web Cryptography API from Web Crypto WG is to define a javascript API for performing basic cryptographic operations in web applications, such as hashing, signature generation and verification, and encryption and decryption.
But according to Gemalto SecureElement API proposal, this spec is to define a javascript API for allowing the communication between web application and a smart card or other secure element by using the Application Protocol Data Units (APDUs) So these would have a relationship but goal and use cases are different.

> -----
> Conclusion
>
> I think it would be helpful to share use cases and requirements and
> also consider the implications of overlap work items.

I agreed for Calendar, Device Capabilities.

>
> In particular, regarding Contacts, we may want to
>
> (a) make sure that the data formats and meaning are consistent (for
> interoperability)

I agreed.

> (b)  ask whether similar APIs across two groups should share a common
> API style  and practices [5] and maybe even details apart from
> optional parameters or intentionally be different (whether it is
> better to enable commonality or make clear distinctions)

Generally I agreed. But there are many descriptions in [5]. So it would be required to review by Sys Apps WG.


Best regards,
Wonsuk.

> Thoughts? I hope this is helpful.
>
> regards, Frederick
>
> Frederick Hirsch, Nokia
> Chair, W3C DAP Working Group
>
> [1] http://www.w3.org/2009/dap/

>
> [2] http://www.w3.org/2012/sysapps/

>
> [3] http://lists.w3.org/Archives/Public/public-device-

> apis/2011Nov/0026.html
>
> [4] http://www.w3.org/2012/webcrypto/

>
> [5] API checklist,  http://www.w3.org/2009/dap/wiki/ApiCheckList

>
> Web API Design Cookbook,
> http://darobin.github.com/api-design-cookbook/

>
> For tracker, complete ACTION-612



Received on Tuesday, 19 February 2013 22:34:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:58 UTC