**** BEGIN LOGGING AT Wed Mar 03 02:59:58 2010 Mar 03 14:01:25 Im trying to test ofono with external modem (available via /dev/ttyACM0) and all I can see is: Unable to read IMSI, emergency calls only. Any hints? Mar 03 17:58:13 dagger: Your modem might not allow IMSI requests over serial/usb/bluetooth Mar 03 17:58:45 dagger: Your only option is a custom driver with a narrower selection of capabilities (e.g. no sim access) Mar 03 23:00:10 denkenz: still phonebook/ef though? Mar 03 23:02:59 phonebook yes, ef no Mar 04 00:29:18 denkenz: ping Mar 04 00:29:24 pong Mar 04 00:30:06 denkenz: thanks for quick comments and we can discuss a lot if you have time now. Mar 04 00:30:46 for [PATCH 4/4] Fix server only return the final parser result, my approach is exactly in my new 2/7 patch Mar 04 00:32:16 and for basic and extended command, we treat them as the same in the internal presentation. e.g., in the same hashtable and could be extensible Mar 04 00:35:06 and for G_AT_SERVER_REQUEST_TYPE_ACTION, i have the same question: do we need to distinguish between SET and ACTION. They are belong to different type of command. Mar 04 00:35:49 two types of command (v.250 5.2.5): action or parameter command Mar 04 00:36:12 for action command, now the type could be ACTION or SUPPORT. Mar 04 00:36:32 for parameter command, the type could be SET, SUPPORT or QUERY. Mar 04 00:37:58 I suggest we simply always do: NONE = AT+FOO, SET = AT+FOO=bar, SUPPORT = AT+FOO=?, QUERY= AT+FOO? Mar 04 00:38:20 The command implementer will figure it out anyway Mar 04 00:39:10 We can even treat AT+FOO as a SET Mar 04 00:39:26 but that one is a strange case anyway Mar 04 00:39:33 different depending on context Mar 04 00:41:16 but that does not follow spec. NONE can be used to check for wrong command. e.g. AT+FOO=*!&. Mar 04 00:41:48 So why bother calling the callback? Mar 04 00:41:54 Simply return the error Mar 04 00:42:12 yes. we can, of course Mar 04 00:42:55 I think we can treat AT+FOO as SET. so NONE can be removed Mar 04 00:43:10 SET is AT+FOO or AT+FOO=bar Mar 04 00:44:30 if it's ok, enum _GAtServerCommandType can be removed and not expose to user Mar 04 00:44:40 Works for me, the simpler the better Mar 04 00:45:05 yeah, i know this part may confuse user but that's defined in V.250 Mar 04 00:45:44 are u ok with my new parser framework? Mar 04 00:45:55 [PATCH 2/7] Add framework of server parser Mar 04 00:47:34 i think you're on the right track yes Mar 04 00:49:01 :-) Mar 04 00:50:19 any other comments? Mar 04 00:51:33 also update the server example with your new changes Mar 04 00:51:43 so i have something to test Mar 04 00:52:36 it's in my TODO list. Mar 04 00:53:52 but how to design the test cases? i need to write a client to atchat with my test-server Mar 04 00:54:48 i wonder if there's more simplier way like unit test under unit/ folder. Mar 04 00:55:26 think of something, at the very least i want code that excercises the new apis Mar 04 00:55:32 so I don't have to write it myself :) Mar 04 00:57:11 ok. i have already have ugly cases. heh. Mar 04 00:58:36 again, for [PATCH 4/4] Fix server only return the final parser result, what's your new approach to let g_at_server_send_result take care of final result Mar 04 00:58:57 i think my current way is good enough though. Mar 04 01:01:17 so I suggest doing it this way: copy the result into a temp buffer in send_result Mar 04 01:01:50 the main driving logic will check what the latest result is (error/ok), if error skip the rest of command line execution and return last result string Mar 04 01:02:03 otherwise continue until all commands executed Mar 04 01:02:13 That way we can easily support custom result codes Mar 04 01:06:51 The buffer can be static too with a reasonable size so we avoid mallocs Mar 04 01:06:55 don't see much difference. current main logic is in server_parse_line. only server_parse_line know when we should return the final result. Mar 04 01:07:21 so the result buffer likes a ring buffer? Mar 04 01:07:23 then I welcome your patch to support +CMS error, +EXT error, +CME error, COMMAND NOT SUPPORT and other jazz Mar 04 01:08:04 hmm...don't touch that part now. Mar 04 01:09:36 can we first use my current way and redesign it later? Mar 04 01:11:22 we're already close to the point that we need a solution anyway Mar 04 01:11:46 so i suggest just solving it now Mar 04 01:13:43 that's fine. and this part should be added first. Mar 04 01:13:59 in my old code, i even add #define AT_SERVER_RESULT_NO_ERROR -1 Mar 04 01:14:39 because in cme_errors, 0 means "Phone failure", and it's conflict with AT_SERVER_RESULT_OK = 0. Mar 04 01:14:51 so it should be fixed first. Mar 04 01:16:05 a simple custom error enum might be enogh Mar 04 01:16:29 what do you mean? Mar 04 01:17:18 AT_SERVER_RESULT_EXT_ERROR Mar 04 01:18:01 so #define AT_SERVER_RESULT_EXT_ERROR -1? that's fine. :) Mar 04 01:18:14 extended errors are not subject to v0/v1 rules Mar 04 01:19:15 -1 might not be a good idea, but any other reserved value would be ok Mar 04 01:19:18 yes, only subject to cmee_format rules, 1 or 0 Mar 04 01:19:57 any suggestion for reserved value? Mar 04 01:20:16 dunno, 0xff? Mar 04 01:20:58 not good enough, 255 has means for cms_error Mar 04 01:21:41 can we hard code only have three kinds of errors, CMS, CME and CEER? Mar 04 01:22:05 don't worry about cme/cms errors Mar 04 01:22:08 the numbers Mar 04 01:22:16 that is an application level problem Mar 04 01:23:02 ok Mar 04 01:23:44 so what Mar 04 01:23:50 sorry Mar 04 01:23:52 typo Mar 04 01:24:30 i still need more think about how to send CMS CME or CEER. Mar 04 01:24:53 i will send some draft codes to u first. Mar 04 01:25:51 sure **** ENDING LOGGING AT Thu Mar 04 02:59:58 2010