Re: GEOPRIV and the W3C Geolocation API

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