**** BEGIN LOGGING AT Mon Dec 14 23:57:06 2009
Dec 15 00:13:25 <zhenhua1> denkenz: ping
Dec 15 00:15:27 <denkenz> pong
Dec 15 00:21:16 <denkenz> holtmann, zhenhua1: I suggest g_at_server or g_at_interface instead of g_at_emu
Dec 15 00:22:21 <zhenhua1> denkenz: i will vote the g_at_server. anyway, it's just a name. both are fine for me.
Dec 15 00:22:34 <holtmann> My vote goes for g_at_server, too.
Dec 15 00:22:43 <denkenz> ok, g_at_server it is then
Dec 15 00:22:55 <holtmann> g_at_modem would be another option.
Dec 15 00:23:38 <denkenz> modem already has too many connotations in plugins & core
Dec 15 00:23:57 <zhenhua1> how about g_at_adapter
Dec 15 00:24:22 <denkenz> adapter is usually adapting something...
Dec 15 00:24:31 <holtmann> Then we go with server.
Dec 15 00:24:47 <zhenhua1> it acts as terminal adapter
Dec 15 00:25:55 <denkenz> Then, we need g_at_server_new_tty, _new_tcp and _new_unix
Dec 15 00:26:15 <denkenz> unix is optional
Dec 15 00:26:15 <zhenhua1> what _new_unix dos for?
Dec 15 00:26:29 <denkenz> same as tcp, but different socket
Dec 15 00:26:39 <denkenz> UNIX is slightly faster through the kernel than TCP
Dec 15 00:27:10 <zhenhua1> can I find any reference code for unix socket
Dec 15 00:27:23 <denkenz> man 7 unix
Dec 15 00:27:28 <zhenhua1> ok
Dec 15 00:27:41 <zhenhua1> got it
Dec 15 00:28:13 <denkenz> _shutdown, _set_debug and set_disconnect_function are fine as is
Dec 15 00:30:33 <zhenhua1> sorry for network problem. i was dropped
Dec 15 00:30:34 <denkenz> no worries, get rid of g_at_emu_send, I don't understand what it does
Dec 15 00:30:34 <zhenhua1> ok
Dec 15 00:30:34 <denkenz> Also get rid of the internal GAtChat, that is wrong
Dec 15 00:30:40 <denkenz> The syntax for command submission is different
Dec 15 00:31:00 <zhenhua1> i know. but syntax is an input for GAtChat.
Dec 15 00:31:09 <zhenhua1> we just need to create server side syntax for chat.
Dec 15 00:31:20 <denkenz> server side syntax is always the same
Dec 15 00:31:36 <denkenz> So you don't need to customize it
Dec 15 00:31:43 <zhenhua1> +xxx: xxx
Dec 15 00:31:46 <zhenhua1> ok
Dec 15 00:31:55 <denkenz> That's response syntax
Dec 15 00:32:10 <denkenz> And we follow 27.007 here according to how V0/V1 is set
Dec 15 00:32:37 <holtmann> Yes. If it doesn't work with the strict parser, we fucked it up ;)
Dec 15 00:33:01 <zhenhua1> i don't have spec now. I will look at V0/V1 later.
Dec 15 00:33:14 <denkenz> So command submission is always ATCOMMAND\r
Dec 15 00:33:26 <zhenhua1> yes.
Dec 15 00:33:28 <denkenz> It is easy to parse and always follows that rule
Dec 15 00:33:53 <zhenhua1> so i believe many api will be same as gatchat.
Dec 15 00:33:59 <denkenz> The server needs to echo / not echo according to E0/E1 and send responses according to V0/V1
Dec 15 00:34:21 <denkenz> Default those options to echo true and v1
Dec 15 00:34:22 <zhenhua1> do we also need the scheduler, writer like gatchat does?
Dec 15 00:34:44 <denkenz> The scheduler is simpler, but yes
Dec 15 00:35:06 <zhenhua1> that's my point. we can reuse that scheduler
Dec 15 00:35:23 <denkenz> of gatchat? Too big a hammer
Dec 15 00:35:34 <zhenhua1> ...
Dec 15 00:35:48 <denkenz> trust me, you don't need it
Dec 15 00:35:59 <denkenz> It will be 50 lines of code to do a new one
Dec 15 00:36:13 <zhenhua1> yes. i will try
Dec 15 00:37:18 <zhenhua1> that's enough for me to spend a week maybe.
Dec 15 00:37:35 <denkenz> Also, lets do g_at_server_add_command do something like:
Dec 15 00:38:21 <denkenz> guint g_at_server_add_command(server, command, expect_pdu, notify, user_data, destroy)
Dec 15 00:38:30 <denkenz> notify should have a signature of
Dec 15 00:39:16 <denkenz> notify(enum GAtServerRequestType type, GAtResult, user_data)
Dec 15 00:39:41 <denkenz> where request type is Set, Support, Query
Dec 15 00:40:08 <zhenhua1> no probs
Dec 15 00:40:56 <denkenz> get rid of add_notify for now, it doesn't belong in g_at_server
Dec 15 00:41:10 <denkenz> And add g_at_server_send_unsolicited()
Dec 15 00:41:20 <zhenhua1> good.
Dec 15 00:41:49 <denkenz> And also do one for g_at_server_send_response()
Dec 15 00:42:03 <denkenz> We might have to do a multiline response for things like COPN, but lets do that one later
Dec 15 00:42:43 <zhenhua1> ok. let's support single response first.
Dec 15 00:43:10 <denkenz> Ok, work on those changes.  I want those in first
Dec 15 00:43:19 <denkenz> And handle all the V250 commands
Dec 15 00:43:26 <denkenz> You can safely ignore most except V & E
Dec 15 00:43:44 <zhenhua1> i need first read V250 and then discuss issues with u
Dec 15 00:44:05 <denkenz> yep, also read 27.007 as it discusses how to implement some of the V250 commands
Dec 15 00:44:13 <zhenhua1> okay
Dec 15 00:44:31 <zhenhua1> i still have opens about how to get response from real modem
Dec 15 00:44:47 <zhenhua1> two ways, through dbus call or API call
Dec 15 00:45:03 <denkenz> Inside oFono? I have to figure that out
Dec 15 00:45:04 <zhenhua1> for manager_dial, i have to use dbus call now
Dec 15 00:45:11 <denkenz> Most likely we make up APIs specifically for AT emulator
Dec 15 00:45:14 <zhenhua1> yes. inside ofono.
Dec 15 00:45:32 <zhenhua1> it needs changes in core part.
Dec 15 00:45:42 <denkenz> It does
Dec 15 00:45:49 <denkenz> I always knew it would :)
Dec 15 00:46:13 <denkenz> For now you can do your testing by proxying to a modem
Dec 15 00:46:19 <zhenhua1> yeah. maybe you need split 1 func to 3...
Dec 15 00:46:29 <denkenz> Even phonesim can work here
Dec 15 00:46:39 <zhenhua1> have details? 
Dec 15 00:46:45 <zhenhua1> how to proxy to a modem?
Dec 15 00:47:01 <zhenhua1> oh
Dec 15 00:47:14 <zhenhua1> that's what i am doing now.
Dec 15 00:48:11 <zhenhua1> what's the parameter for g_at_server_send_response()?
Dec 15 00:49:19 <denkenz> Simple, open up a g_at_server and inside connect a gatchat to phonesim
Dec 15 00:49:23 <denkenz> then just send commands as is to phonesim and send back what it sends
Dec 15 00:49:24 <denkenz> Simple AT emulator, but you can check that all your formatting, etc is correct
Dec 15 00:49:30 <denkenz> the response string and the error
Dec 15 00:49:35 <denkenz> The error should be like CMS/CME/OK/ERROR
Dec 15 00:49:35 <denkenz> Let the function figure out what to send according to V setting
Dec 15 00:52:34 <zhenhua1> ok. i will try it so see what happens.
**** BEGIN LOGGING AT Tue Dec 15 01:17:44 2009
**** BEGIN LOGGING AT Tue Dec 15 02:11:45 2009
Dec 15 02:31:30 <denkenz> zhenhua1: That reminds me, you might also want to look into how to support compound commands
Dec 15 02:31:55 <denkenz> e.g. ATCMD1 CMD2=foo +CMD3=blah; +CMD4=bar\r
Dec 15 02:31:57 <zhenhua1> example?
Dec 15 02:32:11 <zhenhua1> yes
Dec 15 02:32:28 <zhenhua1> so it's the parser work in g_at_server
Dec 15 02:32:36 <denkenz> yep
Dec 15 02:32:48 <zhenhua1> i need figure out how to do that.
Dec 15 02:33:01 <zhenhua1> so i need another server side syntax
Dec 15 02:33:19 <denkenz> Again, this is set in stone
Dec 15 02:33:29 <denkenz> So you can just hardcode the behavior, as long as it is per spec
Dec 15 02:34:19 <zhenhua1> yes.
Dec 15 02:40:40 <zhenhua1> denkenz: ATCMD1 CMD2=foo\r. It looks I need to put them into a queue, and execute them in order.
Dec 15 02:41:10 <zhenhua1> denkenz: if the first command result is wrong, we return ERROR\r\n back. right?
Dec 15 02:41:42 <denkenz> If the first one fails we return whatever error it fails with
Dec 15 02:42:06 <denkenz> if the second one fails, we return whatever error it fails with, but we also print any intermediate response of the first command
Dec 15 02:42:08 <zhenhua1> yes
Dec 15 02:43:01 <zhenhua1> return first+second at one time? or return first response, then return second fail?
Dec 15 02:45:45 <denkenz> there's only one final response
Dec 15 02:46:14 <denkenz> If first command doesn't have an intermediate response, then we simply return error
Dec 15 02:46:57 <zhenhua1> i see
**** ENDING LOGGING AT Tue Dec 15 02:59:57 2009