RE: api comments

My responses inline to certain comments you asked questions on or raised
issue with my comment.

Allan


> Comment #6:
>
> This API provides a mechanism to provide location of the calling  
> agent ONLY. Might be obvious but I think it is worth stating due to  
> security concerns that may arise if someone thought they can use  
> this API to find out location of someone else.


I do not follow this argument.  There are lots of things that this API  
doesn't do that we are not enumerating.  What are you proposing we  
state here?

AT: Suggest adding a statement that this API provides the location of
the calling agent only. Either in the scope or requirements section.

>
> API Description - Geolocation Interface
>
> Comment #7:
>
> interface Geolocation {
>     void getCurrentPosition(in PositionCallback successCallback);
>     void getCurrentPosition(in PositionCallback successCallback, in  
> PositionErrorCallback errorCallback);
>     void getCurrentPosition(in PositionCallback successCallback, in  
> PositionErrorCallback errorCallback, in PositionOptions options);
>
>     int watchPosition(in PositionCallback successCallback);
>     int watchPosition(in PositionCallback successCallback, in  
> PositionErrorCallback errorCallback);
>     int watchPosition(in PositionCallback successCallback, in  
> PositionErrorCallback errorCallback, in PositionOptions options);
>
>
> Are these methods completely orthogonal (i.e. thread safe)?
>
> i.e. can a client call multiple methods at the same time before a  
> result is received? What are the semantics of multi-threading  
> applications on this API. Suggest they should be thread safe and a  
> client can call methods multiple times without waiting for a  
> result.  If that is the case then each call of the method should  
> return a unique handle as part of the registration if the client is  
> to be able to differentiate results to each call of a method  
> especially if they are using the same callback method.


This is an implementation detail.

AT: Considering it has implications on the signature of the method and
possibly the semantics of the method I'm not sure I agree its purely an
implementation detail. I think it's a spec issue too.

> Comment #8:
>
>   interface PositionCallback {
>     void handleEvent(in Position position);
>   };
>
>   interface PositionErrorCallback {
>     void handleEvent(in PositionError error);
>   };
>
>
> Why are there two functions rather than just one function with a  
> status code? For example there may be situations where a location  
> object will be returned but some additional status still needs to be  
> conveyed back to the caller also. In that case there is no way to do  
> that right now. Also, having two methods will create code bloat  
> unnecessarily.
>
> Suggest make a single method for callback with a status object (code  
> + other attributes) and a location position object.
>

It models the XHR.  This was discussed previously on the mailing list.

AT: OK. So I wasn't part of that previous discussion and saying that it
models something else does not address my point.


> Another possible option is to define a polygon and error estimates  
> on the location result so that you can represent accuracy more  
> correctly. To do this see comment regarding X,Y positional  
> information in civic attributes.

no polygons in this API. please.

For most location determination systems a polygon with a center point
represents a more realistic view of how location is determined. For many
user applications they can use the centerpoint of the polygon but for
some other applications that want to show the "error" with the location
estimate they need this information. To simply show an circle around a
person's location is frankly misleading and wrong. I understand the
desire to simplify how location is represented but it frankly is not
that simple in a RF world to represent location as a single point or a
point with a circle around it.

>
> API Description - Coordinates Interface
> API Description - Address Interface
>
> Comment #12:
>
>   interface Address {
>     readonly attribute DOMString country;
>     readonly attribute DOMString region;
>     readonly attribute DOMString county;
>     readonly attribute DOMString city;
>     readonly attribute DOMString street;
>     readonly attribute DOMString streetNumber;
>     readonly attribute DOMString premises;
>     readonly attribute DOMString additionalInformation;
>     readonly attribute DOMString postalCode;
>   };
>
> This object is missing attributes for
>
> 1)       Building
> 2)       Floor
> 3)       Area
> 4)       X,Y (on a floor) or a polygon that represents the position  
> and error at the same time
>
> Comment #13:
>
> AdditionalInformation is inadequate for the "rest" of the  
> information for buildings, floors...etc as the spec currently states.


Why is it inadequate?  Isn't there a conversion possible?
Why is it inadequate?  Isn't there a conversion possible?

AT: It is inadequate because many enterprises that have multiple
buildings like to represent civic location based on campus (e.g San Jose
Main Campus), building names (e.g. Building 10) NOT purely street
addresses (which is still usefull). Also floor and position on the floor
are very important. 

If you have an application providing location of a conference room it
would be good to be able to represent that conference room as well as
floor, building and campus name all as separate fields rather than
compressing the information into a single "additional" field.

Received on Monday, 30 March 2009 18:27:19 UTC