**** BEGIN LOGGING AT Thu Dec 30 02:59:58 2010 Dec 30 12:42:40 Would it be against oFono design principles to include a retry logic for function callback that eventually results in modem query or should we let the client do the retrying if oFono reports error in operation? Dec 30 14:26:41 demarchi: are you around? Dec 30 14:28:22 emdete: yeah Dec 30 14:31:26 demarchi: could you add the RFSWITCH command to the huawei code? Dec 30 14:33:25 emdete: i'm not sure where it's needed Dec 30 14:34:49 demarchi: just before the AT+CFUN=1 and after =0 Dec 30 14:35:00 and probably only for the em770 Dec 30 14:41:03 demarchi: it's probably a piece of cake for you but hours for myself... Dec 30 15:29:08 denkenz: holtmann : hi. For the gps atom task, as you know, I am working with mbm for a driver. When gps is powered we have to send AT*E2GPSNPD to the GPS port to get the NMEA stream. What do you advice for this?. Should the driver->enable() to send AT*E2GPSNPD to the GPS port? Or, should it be sent by users/applications which want to get the nmea flow? Dec 30 15:29:42 by the modem driver Dec 30 15:32:05 denkenz: okey, and.. Dec 30 15:34:59 denkenz: also, for the mbm plugin, on the gps atom task you reviewed, had data->gps_port = create_port(gps_dev).. But, that should not be needed right? (because we would use data->modem_port in ofono_gps_create and for gps AT commands) Dec 30 15:35:30 essentially yes Dec 30 15:36:08 denkenz: great, thanks Dec 30 15:47:58 zrafa: will ofono do the nmea/(whatever) parsing? Dec 30 15:48:55 emdete: .. you mean something liks gpsd ? Dec 30 15:49:33 zrafa: i mean translating the nmea to some usefull dbus events or the like Dec 30 15:52:36 emdete: I would not say.. You can see features coming reading TODO Dec 30 15:53:41 zrafa: so what's the plan for gps? switching it on & spawn anohter prog like gpsd? Dec 30 16:37:33 emdete: oFono is not going to try to become gypsy/gpsd Dec 30 16:37:53 denkenz: okay. i just asked because it is pppd already ;) Dec 30 16:38:19 we're pppd because pppd is a PoS Dec 30 16:39:04 There's simply no easy way to integrate that beast nicely Dec 30 16:39:24 so how will gps integrate "nicely"? Dec 30 16:40:52 so ofono will switch it on/off, if the modem requires that the device is the same as the one spitting out nmea it has to release/close the dev and somehow tell someone which device to use to read nmea from. right? Dec 30 16:41:27 for mbm there will be no impact, we're not using the 3rd port provided by mbm anyway Dec 30 16:41:51 but potentially you might have reduced capability, e.g. no mms context while gps is active Dec 30 16:42:06 denkenz: ofono opens the 3rd port, issues the command to switch nmea on, closes the port & that's it? Dec 30 16:42:12 yep Dec 30 16:42:39 denkenz: so a client asks ofono to do so, where does the client know which port to open afterwords? Dec 30 16:43:01 the LocationReporting interface of oFono? Dec 30 16:43:20 and that will contain the plain file/devicename...? Dec 30 16:43:22 you should really subscribe to the mailing list Dec 30 16:43:28 this was discussed to death already Dec 30 16:43:49 and the answer is yes ;) Dec 30 16:43:51 more easy: this should be documented Dec 30 16:44:30 denkenz: my ml folder already contains 27K mails. i am subscribed to alot of ml. so i stopped subscribing to more... sry Dec 30 16:44:48 I understand, but at some point I will stop answering your questions Dec 30 16:44:59 denkenz: as i said: docs help alot Dec 30 16:45:34 denkenz: especially 'cause i am not interested in the discussion but in the implemented solution ;) Dec 30 16:46:14 the API proposal was on the mailing list, you will have to wait for the docs when the patches are accepted upstream Dec 30 17:05:01 emdete: hey, just create a gmail account to subscribe to mailing lists and separate them by labels Dec 30 17:05:14 it's easy Dec 30 17:12:15 demarchi: most things are just easy. you didn't understand my prob: i have no time left for that Dec 30 17:31:45 denkenz: if the text and icon check needs to be done in stkutil, then we have to touch all the parsing functions Dec 30 17:32:16 you do this inside stk.c anyway Dec 30 17:33:04 The logic for whether a proactive command is valid or not belongs in stkutil, not stk.c Dec 30 17:33:17 That way those corner cases can be properly unit tested Dec 30 17:37:07 agree, thats also one of the reason i sent it as rfc patch Dec 30 17:37:37 I'll do the reguired changes and send the final patch Dec 30 19:44:27 denkenz: ping Dec 30 19:58:54 yes? Dec 30 20:04:19 currently, stkutil unit test cases are handling only success cases Dec 30 20:05:01 we have to add cases for handling the failure case as well or we need to remove some of the unit test cases Dec 30 20:05:57 adding explicit failure tests is fine Dec 30 20:06:37 ok **** ENDING LOGGING AT Fri Dec 31 02:59:58 2010