[PATCH 4/4] Save CellBroadcast Topics list, handle EF-CBMI, EF-CBMIR.

[Andrzej Zaborowski]

Hi,

2009/12/16 Denis Kenzior <denkenz at gmail.com>:
>> The two SIM files are only used to bootstrap the topics list value
>> if there's no previous value.  I think there's no point in updating
>> their contents because if the user adds new ranges, most likely the
>> list will not fit the file sizes and writing will fail so we will need
>> to use the copy from IMSI based storage.  And if we use our copy then
>
> If you want to be really nice, you can actually optimize the ranges, then
> write the first n entries in cbmir and m entries into cbmi when the user sets
> the property.  n and m are the sizes of those files respectively.
>
> Then at startup always read cbmir and cbmi and union them with the set
> obtained from settings.

This would mean we would be kind of ignoring entries that the user
deleted "elsewhere" (outside ofono control).  We're losing some
information either way so I think we should go for the simplest thing.

>
>> we won't detect changes made to these files when ofono wasn't running.
>> (Basically we have a choice between storing new values in the SIM or
>> our own storage, but doing both things doesn't make sense)
>
> Since you took this approach, can we optimize the flow a little bit?  You can
> count on the sim atom (along with the IMSI) always being there before cbs
> atom, the present code even does this.  So we can check right away whether the
> topic ranges are set in our settings store.  So lets do something like:
>
> 1. Check IMSI store, if Topics are present, read them, goto step 3
> 2. Read EFcbmi and EFcbmir
> 3. Check Powered or set default to false.  If powered enable the topics if we
> have them.
> 4. Read EFcbmid (this will be cached most of the time anyway)
> 5. Once EFcbmi and EFcbmir are read, bootstrap the topic list and make sure to
> emit the property changed signal.
> 6. Once EFcbmid is read, update the internal list (including sending it to the
> modem), but the topic list property remains the same.

Is there any point enabling Powered that early, i.e. before the other
files are read?  This also seems like an unneeded complication.

Regards