**** BEGIN LOGGING AT Wed Mar 24 02:59:57 2010
Mar 24 03:16:08 <zhenhua1> denkenz: any comments for my updated patch?
Mar 24 03:57:30 <denkenz> zhenhua1: I look at it tomorrow
Mar 24 07:37:13 <akiniemi> tck: the modem image on N900 can be updated, but it's unlikely that the filter rules are going to change 
**** BEGIN LOGGING AT Wed Mar 24 21:08:15 2010
Mar 24 22:39:07 <holtmann> denkenz: I don't like this casting with g_free into a function with different parameters.
Mar 24 22:40:03 <denkenz> holtmann: I got this from BlueZ/Connman btw
Mar 24 22:40:19 <holtmann> ConnMan doesn't have it.
Mar 24 22:40:31 <denkenz> holtmann: And IMO it beats creating pointless functions
Mar 24 22:40:57 <holtmann> I know that BlueZ has it. It doesn't make it better. We had a few issues with GFunc casts in the past.
Mar 24 22:42:02 <holtmann> Keep it as g_free at least. No other function casting. That will break eventually and the compiler will never warn you.
Mar 24 22:42:41 <denkenz> holtmann: The intention always was to only do this for g_free
Mar 24 22:43:00 <denkenz> holtmann: Other functions are no-no for reasons just stated
Mar 24 22:43:17 <denkenz> holtmann: However having 4-5 line pointless functions for everything is worse than this cast
Mar 24 22:50:37 <holtmann> Okay.
**** BEGIN LOGGING AT Thu Mar 25 00:31:41 2010
Mar 25 00:32:51 <denkenz> holtmann: The CONNECT <baud> should work
Mar 25 00:33:42 <denkenz> holtmann: Or not, kristen never submitted that patch :(
Mar 25 00:42:51 <denkenz> holtmann: Should be fixed now
**** BEGIN LOGGING AT Thu Mar 25 02:04:33 2010
Mar 25 02:05:09 <ygu5_ubuntu> denkenz: ping
Mar 25 02:05:18 <denkenz> pong
Mar 25 02:06:46 <ygu5_ubuntu> I have looked at your comments. Just need some clarification.
Mar 25 02:07:09 <ygu5_ubuntu> First is about the MMS or MM.
Mar 25 02:07:33 <ygu5_ubuntu> In 102.223, section 8.85 is MM Content idnetifier
Mar 25 02:07:50 <ygu5_ubuntu> 8.84, Multimedia Message Transfer status
Mar 25 02:08:07 <ygu5_ubuntu> So I unify all the names to be MM.
Mar 25 02:08:18 <ygu5_ubuntu> Do you think MMS is a better name?
Mar 25 02:08:20 <denkenz> I know, but use your head here, people looking at FOO_MM will have no idea wtf it is until they read the spec
Mar 25 02:08:27 <denkenz> FOO_MMS and they immediately know
Mar 25 02:09:18 <ygu5_ubuntu> I'm fine to unify them all to be MMS. I just want to keep them unified.
Mar 25 02:09:35 <denkenz> I prefer MMS there
Mar 25 02:10:44 <ygu5_ubuntu> Sure, I will unify them to be MMS. The spec doesn't write these in a unified form. Some place is mm, while at other place is mms.
Mar 25 02:11:22 <ygu5_ubuntu> 8.86: Multimedia Message Notification. But the field in it is "MMS notification message" ;)
Mar 25 02:11:32 <ygu5_ubuntu> I will unify them.
Mar 25 02:11:52 <denkenz> In the end the order doesn't matter
Mar 25 02:11:58 <denkenz> As long as we understand what it is
Mar 25 02:12:03 <ygu5_ubuntu> The second is about parse_dataobj_common_bool()
Mar 25 02:12:41 <ygu5_ubuntu> The other case is 8.43: immediate response
Mar 25 02:12:49 <ygu5_ubuntu> You have implemented this one.
Mar 25 02:13:13 <ygu5_ubuntu> But I think we can reuse parse_dataobj_common_bool() to rewrite 8.43
Mar 25 02:14:03 <denkenz> Ah, ok sounds good to me
Mar 25 02:14:17 <denkenz> send a patch with both though, otherwise I got confused
Mar 25 02:14:25 <ygu5_ubuntu> In general, I find we can implement some other common functions similar to parse_dataobj_common_bool(), such as parse_dataobj_common_byte(), parse_dataobj_common_byte_array(). 
Mar 25 02:15:00 <ygu5_ubuntu> So that we can implement some parser in an easier way.
Mar 25 02:15:05 <ygu5_ubuntu> I will send out the patch.
Mar 25 02:15:19 <denkenz> Probably text too
Mar 25 02:15:35 <ygu5_ubuntu> yes.
Mar 25 02:15:39 <denkenz> Since the whole ucs2/gsm/gsm squished is done multiple places
Mar 25 02:15:57 <denkenz> And yeah I'm fine with that, but in your commit messages explain it
Mar 25 02:16:09 <ygu5_ubuntu> The patch is just a trial, so that I can make sure you buy in this concept.
Mar 25 02:16:19 <denkenz> I tend to look through all patches before commenting, so if your patch does something strange and is out of context I have no idea what you mean
Mar 25 02:17:05 <ygu5_ubuntu> Sure. I have implemented all the parsers. So I have the idea to extract the common part. 
Mar 25 02:18:18 <ygu5_ubuntu> Can I parse help_request and modify immediate response in a single patch?
Mar 25 02:18:34 <denkenz> I'd do it in three
Mar 25 02:18:47 <denkenz> add common_bool, migrate imm response, add help request
Mar 25 02:19:00 <ygu5_ubuntu> OK. I will do this way.
Mar 25 02:19:02 <denkenz> Then it is clear what you're doing
Mar 25 02:19:18 <ygu5_ubuntu> yes
Mar 25 02:20:13 <ygu5_ubuntu> Last question is about lac_tac.
Mar 25 02:20:27 <ygu5_ubuntu> I saw a structure in simutil.c
Mar 25 02:20:34 <ygu5_ubuntu> struct opl_operator {
Mar 25 02:20:34 <ygu5_ubuntu> 	char mcc[OFONO_MAX_MCC_LENGTH + 1];
Mar 25 02:20:34 <ygu5_ubuntu> 	char mnc[OFONO_MAX_MNC_LENGTH + 1];
Mar 25 02:20:34 <ygu5_ubuntu> 	guint16 lac_tac_low;
Mar 25 02:20:34 <ygu5_ubuntu> 	guint16 lac_tac_high;
Mar 25 02:20:35 <ygu5_ubuntu> 	guint8 id;
Mar 25 02:20:35 <ygu5_ubuntu> };
Mar 25 02:20:59 <ygu5_ubuntu> The lac_tac_low and lac_tac_high here are two different lac_tac?
Mar 25 02:26:24 <denkenz> No, that one is a little different
Mar 25 02:27:00 <denkenz> That one gives a range of LAC to consider equivalent, and a special set of special wildcard ones
Mar 25 02:27:44 <denkenz> Think the if low is 0000 and high is FFFE then it is wildcard
Mar 25 02:28:00 <ygu5_ubuntu> A range, ok, it makes sense.
Mar 25 02:28:30 <denkenz> For you, just use unsigned short lac_tac or something, then unsigned short for ci and unsigned short for extra_ci
Mar 25 02:28:49 <ygu5_ubuntu> ok
Mar 25 02:30:24 <ygu5_ubuntu> I'm done with questions :)
**** ENDING LOGGING AT Thu Mar 25 02:59:57 2010