Future of location services on OM

[Onen]

Michael 'Mickey' Lauer wrote:
> Am Monday 19 January 2009 18:13:41 schrieb Onen:
>   
>> Michael 'Mickey' Lauer wrote:
>>     
>>> Am Thursday 15 January 2009 22:52:40 schrieb Onen:
>>>       
>>>> To be sure of the tuple I log, I
>>>> prefer to get everything in a single shot. Moreover, I prefer to receive
>>>> signals instead of calling monitor methods every time I want to log
>>>> something, I guess this saves CPU, thus power.
>>>>         
>>> There are no unsolicited responses from the monitor for these
>>> information, you have to poll for them. What we could do is cover this in
>>> the framwork, but then we might as well let the application define the
>>> update granularity / data accuracy.
>>>
>>> s/monitor/modem/
>>>       
>> Not sure to understand what you mean by unsolicited responses from the
>> modem. The framework sends a signal
>> (org.freesmartphone.GSM.Network.Status), following the GSM specs. Do you
>> mean that under the hood, the framework does polling, because the modem
>> does not have this kind of unsollicited signal?
>>     
>
> We're talking about two different kind of things. 
> org.freesmartphone.GSM.Network.Status is about the gsm registration 
> information as defined by 07.07 -- for this there are unsolicited response 
> codes defined and we're using them.
>
> org.freesmartphone.GSM.Monitor is the new addition to ogsmd, giving you 
> detailed information about not only the serving cell but also up to 6 
> neighbour cells in range. This one is not defined in 07.07 and there are no 
> unsolicited response codes, therefore we do not offer a signal.
>
>   
Then we agree. Maybe I was unclear, but I wanted to say that I use the
org.freesmartphone.GSM.Network.Status
signal at the moment to get MCC, MNC, lac, cell-id, etc. in one shot. 
And I prefer to keep using it, instead of switching to the new 
monitoring interface because I would need to use polling.

Onen