Re: Seeking feedback on a new WG to specify APIs for device services

> 1. While we welcome Nokia's "straw person" proposals as starting
> points (and the royalty-free declarations on patents that accompany
> the straw persons), we continue to be uncomfortable that a _new_ WG
> is coined for the purpose of creating APIs exposed to scripting
> contexts on the web.

I don't think there is a clear cut explanation of why a brand new WG
is necessary. Let me list some concerns that could be raised if we do
this in WebApps:

- load on Chairs and Team contacts. Those folks are expected to know
  what's going on in the Group. Are we just expecting to take on the
  extra work?

- IP scope. The more we'll go into APIs that are heavily used in the
  mobile market, the more likely it will raise concerns over patent
  portfolios. This might not be a concern for Mozilla but I wouldn't
  like to have to participate in 2 or 3 PAGs for WebApps (as a
  reminder, we already have one). Of course, a counter argument would
  be that it's better to face those issues now, but it will make my
  first point about workload even stronger.

- Where do we stop? Should we put a boundary to the set of Web APIs
  developed in the WebApps Group? This is not the first request that
  I'm getting to add more APIs into that Group. We already have 23
  deliverables in that Group. Some of them haven't been updated since
  April 2006, like the Window object specification.

Don't get me wrong. I do believe that the APIs submitted by Nokia
provided some important functionalities and we shouldn't wait several
months before starting an effort on them.

> 2. Again, while we have concern that a new WG is required, we also
> have concern that charter approvals for extensions to an existing
> activity's scope take far too long. In practice, I have not seen
> evidence that proposing new topics for exploration within a healthy
> space (such as Web Apps) works efficiently.  This is distressing to
> see; I'd like commentary about why this is, and what can be done to
> expedite this.  I am particularly concerned that it may prove faster
> to coin a new WG than approve a charter amendment to an existing WG.
> Why is this?

Part of today's problem is that we don't do charter amendment. For
example, to add Web Workers into the set of deliverables of WebApps, we
had to get a complete charter to the AC for review. It triggered
comments that were not related to that particular addition but on other
aspects, like CORS or Widgets. It may make things easier if we don't
have to review the entire charter in order to add an additional
deliverables but, as usual, there are some pros and cons to the
approach. As Art pointed out, part of the discussion happens prior to
the AC review. In the case of the device APIs, one of the issues is
indeed about whether it should be into WebApps or not. My position is
that it can only be there if we increase Chairs and Team contacts
resources at the minimum. Dominique Hazaël-Massieux is taking the lead
on device APIs at the moment. We're still certainly interested in
feedback in any case.

Philippe

Received on Monday, 4 May 2009 20:10:02 UTC