Re: GEOPRIV and the W3C Geolocation API

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