Re: System Level APIs draft proposal

Hi Robin
On 2 maj 2012, at 17:28, Robin Berjon wrote:

> Hi Niklas,
> 
> On May 2, 2012, at 11:33 , Niklas Widell wrote:
...
> No, I don't think it's a find-the-implementers issue. The motivation for keeping those separate is that the designs for APIs on either side tend to be very different, and also held up by different problems. Putting them in the same group creates confusion (as I think you will remember from the early days of DAP).

I don't agree, I think it creates more confusion to have one Messaging API in DAP and another Messaging api in SL WG covering similar things but to different degrees and capabilities. In addition, a sub-goal should be to expose as much as possible of APIs to any web developer, which I believe is facilitated by a combined WG. 
My impression of early days of DAP was classic culture-clash over security. Given that there is some substantial implementer interest from B2G, Tizen, etc, I hope there is now a situation where the security solutions can be discussed in a more fruitful way. 

> Also, apart from Mozilla who are doing both a browser and B2G, most of the time the other implementers are very different people depending on the API type. I think it's better to allow these communities to exist in separation and not be forced to hear about one another's problems, most of which they might not care about. It keeps things more manageable.

I'd rather avoid having two groups designed to diverge working with different specifications for same functionality. I'm not sure that is beneficial in the long run unless the intent is to strongly separate open/browser web from curated web. 

>> (n.b. There are also a couple of APIs in the proposal that does not have
>> corresponding DAP apis, I see no reason why these couldn't be added to DAP
>> charter, actually added back for a couple of them)
> 
> Can you please specify which ones you are thinking of? DAP is looking at changing its charter so it could be useful to know.
Bluetooth, background services (in DAP or Web Apps), device capabilities would be candidates. 

> -- 
> Robin Berjon - http://berjon.com/ - @robinberjon
> 

/niklas