- From: Doug Schepers <schepers@w3.org>
- Date: Mon, 01 Jul 2013 00:10:11 -0400
- To: Jon Williams <jon@shovemedia.com>
- CC: public-geometryapi@w3.org
Hi, Jon- On 6/28/13 4:17 PM, Jon Williams wrote: > >> Thanks for getting this going. > > Second that. Thanks! I'm glad there's interest! > I'm curious about the scope of this effort. I can think of a billion > uses for primitive geometry calculations, but I feel like this project > needs a short list of example use cases that the browser manufacturers > can't easily dismiss with "use JavaScript". I think you hit the nail on the head. To me, I think this effort will be most effective if it focuses on a cohesive set of methods that either make complex operations easier or significantly faster, or make nigh-impossible things possible. As you say, a geometry API could do any number of things, but in the end, it should just be supplemental to the code authors will have to write anyway, just as the JS Math object gives basic math primitives. In the Web Audio WG, we had good success with establishing what we wanted it to accomplish by laying out our use cases, and deriving requirements from that; we started with all the use cases we could think of that might be useful, then discussed their relative priority; for medium or high priority items, we wrote requirements that covered them. The more (and higher-priority) use cases that a particular requirement met, the more important we decided it was. I took the liberty of starting a Use Cases and Requirements page [1], based on the format we used for the Web Audio API. I also agree that we should make an effort to be disciplined in what we decide are priorities, because we need to make something that browsers will actually implement and ship! And that same discipline will help us focus and get something done in a reasonable time frame. [1] http://www.w3.org/community/geometryapi/wiki/Use_Cases_and_Requirements Regards- -Doug
Received on Monday, 1 July 2013 04:10:19 UTC