RE: RFC: Neighbouring Cell Info, take 2

2010-02-12 Thread Aki Niemi 
to, 2010-02-11 kello 20:25 +0100, ext Bastian, Waldo kirjoitti:
   void ofono_cell_info_query(struct ofono_cell_info *ci,
  ofono_cell_info_query_cb_t cb, void *data);
  
  What's this for?
 
 It's basically ofono_cell_info_driver-query(...) for use by a plugin after 
 it has acquired the atom, something like:
 cell_info_atom = __ofono_modem_find_atom(modem, OFONO_ATOM_TYPE_CELL_INFO);
 cell_info = __ofono_atom_get_data(cell_info_atom);
 ofono_cell_info_query(cell_info, plugin_query_cb, plugin_data);

Right, but if the atom already exposes a D-Bus API, what is the purpose
of this plugin interface?

Cheers,
Aki

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: RFC: Neighbouring Cell Info, take 2

2010-02-12 Thread Bastian, Waldo 
 to, 2010-02-11 kello 20:25 +0100, ext Bastian, Waldo kirjoitti:
void ofono_cell_info_query(struct ofono_cell_info *ci,
   ofono_cell_info_query_cb_t cb, void *data);
  
   What's this for?
 
  It's basically ofono_cell_info_driver-query(...) for use by a plugin
 after it has acquired the atom, something like:
  cell_info_atom = __ofono_modem_find_atom(modem,
 OFONO_ATOM_TYPE_CELL_INFO);
  cell_info = __ofono_atom_get_data(cell_info_atom);
  ofono_cell_info_query(cell_info, plugin_query_cb, plugin_data);
 
 Right, but if the atom already exposes a D-Bus API, what is the purpose
 of this plugin interface?

It's either a D-Bus API or a plugin interface and Denis indicated a preference 
for a plugin interface over a D-Bus API. I think his main concern was over the 
maturity of the API, so maybe he can be pursuaded otherwise now that this is 
based off the OMA SUPL standard.

Cheers,
Waldo
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: RFC: Neighbouring Cell Info, take 2

2010-02-11 Thread Bastian, Waldo 
  struct ofono_cell_info_driver {
  const char *name;
  int (*probe)(struct ofono_cell_info *ci, unsigned int vendor,
  void *data);
  void (*remove)(struct ofono_cell_info *ci);
  void (*query)(struct ofono_cell_info *ci,
  ofono_cell_info_query_cb_t cb,
  void *data);
  };
 
  void ofono_cell_info_query(struct ofono_cell_info *ci,
 ofono_cell_info_query_cb_t cb, void *data);
 
 What's this for?

It's basically ofono_cell_info_driver-query(...) for use by a plugin after it 
has acquired the atom, something like:
cell_info_atom = __ofono_modem_find_atom(modem, OFONO_ATOM_TYPE_CELL_INFO);
cell_info = __ofono_atom_get_data(cell_info_atom);
ofono_cell_info_query(cell_info, plugin_query_cb, plugin_data);

Cheers,
Waldo
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Re: RFC: Neighbouring Cell Info, take 2

2010-02-10 Thread Aki Niemi 
to, 2010-02-11 kello 01:23 +0100, ext Bastian, Waldo kirjoitti:
 Revisited proposal for neighbouring cell info based on previous
 feedback:
 - Low-level driver API instead of oFono.org DBUS API 
 - Polling based, no automatic periodic updates
 - Follows definitions in OMA SUPL v2.0

I like it.

 I'm not particular fond of the nested list - wcdma.
 measured_results_list[].cell_measured_results[], maybe flatten that
 into a single list?

I agree it's ugly, but I'd keep it like that in the driver API, and
possibly flatten it in the D-Bus API if necessary.

 struct ofono_cell_info_driver {
   const char *name;
   int (*probe)(struct ofono_cell_info *ci, unsigned int vendor,
   void *data);
   void (*remove)(struct ofono_cell_info *ci);
   void (*query)(struct ofono_cell_info *ci,
   ofono_cell_info_query_cb_t cb,
   void *data);
 };
 
 void ofono_cell_info_query(struct ofono_cell_info *ci, 
 ofono_cell_info_query_cb_t cb, void *data);

What's this for?

Cheers,
Aki

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono