- From: Doug Turner <doug.turner@gmail.com>
- Date: Tue, 11 Nov 2008 10:40:28 -0800
- To: Aaron Boodman <aa@google.com>
- Cc: Richard Barnes <rbarnes@bbn.com>, Andrei Popescu <andreip@google.com>, public-geolocation <public-geolocation@w3.org>
On Nov 11, 2008, at 10:37 AM, Aaron Boodman wrote: > On Tue, Nov 11, 2008 at 10:19 AM, Richard Barnes <rbarnes@bbn.com> > wrote: >> On the contrary, the point of APIs being compatible with RFCs is to >> minimize >> "transcoding" between two standards. The API specifies the formats >> and >> interactions within a host, and the RFC specifies what formats and >> interactions on the wire. >> >> If it's going to use network services, the code that implements the >> API has >> to think in API terms on one side and in RFC terms on the other. >> If these >> are dramatically different (say, if the email API wanted addresses >> as images >> for anti-spam purposes), then the API has to translate. The point >> of making >> the API compatible with the RFC is to make this translation easy. >> >> If you know that you're going to have code that has a particular >> protocol on >> the back end, then having APIs that match up well against the >> corresponding >> RFCs minimizes the risk of mis-interpretation and makes >> interoperability >> easier. In this case, given that GEOPRIV protocols are the Internet >> standard protocols for a host to acquire location, it's very likely >> that >> code will want to use them on the back end, so it makes sense for >> the API to >> be compatible with them. > > It's true that API design can sometimes be limited by the underlying > wire format. However, that is not a problem here. If geopriv became > very popular and we wanted to add support for it, that would be easy > to do in a v2 of this API. We'd only need to add a rules object to the > Position interface. > > - a +1
Received on Tuesday, 11 November 2008 18:41:12 UTC