**** BEGIN LOGGING AT Thu Jan 06 02:59:58 2011
Jan 06 17:05:40 <leiyu> denkenz: u there?
Jan 06 17:12:42 <FaiyazBaxamusa> hi
Jan 06 17:14:52 <FaiyazBaxamusa> denkenz: as part of working on CDMA SMS TX path I see that on GSM stack we have a "org.ofono.Message"
Jan 06 17:18:29 <FaiyazBaxamusa> denkenz: This code can be common and can be reused by CDMA stack.  I have reworked  "org.ofono.Message" code so that it is no longer just part of sms.c file and have created a separate file for the same. Do you have thoughts on the same or should I just go ahead and submit the patch for review. 
Jan 06 17:44:13 <denkenz> leiyu: yes?
Jan 06 17:44:50 <denkenz> FaiyazBaxamusa: Sure feel free
Jan 06 17:45:02 <leiyu> denkenz: Just wanted to check with you on cdmaphonsim stuff. I just replied your post in the mailing list. Pls check to see if my understanding is correct or not.
Jan 06 17:45:15 <FaiyazBaxamusa> denkenz: thanks
Jan 06 17:46:33 <denkenz> leiyu: yep, that is what I meant
Jan 06 17:47:06 <denkenz> we need to modify both phonesim and cdmaphonesim
Jan 06 18:49:05 <holtmann> I just uploaded ofono-0.38 release.
Jan 06 19:05:32 <demarchi> denkenz: ping
Jan 06 19:17:44 <Jeevaka> holtmann: any release notes for this release?
Jan 06 19:18:13 <denkenz> demarchi: pong
Jan 06 19:19:58 <holtmann> Jeevaka: See ChangeLog and I think Denis will send out an announcement at some point.
Jan 06 19:20:11 <holtmann> Jeevaka: Mostly bug fixes actually.
Jan 06 19:20:21 <demarchi> denkenz: any news on the retry counters patch?
Jan 06 19:21:17 <denkenz> nope, sorry had to deal with some other things
Jan 06 19:21:19 <Jeevaka> holtmann: currently main page of ofono is having release info for 0.33, it would be nice if we can have the latest releases posts available in the main page
Jan 06 19:29:36 <demarchi> denkenz: ok, np.... i'm willing to send the patches for cdip task
Jan 06 19:29:47 <demarchi> denkenz: but i think i'll wait until tomorrow
Jan 06 22:11:05 <leiyu> denkenz: hi
Jan 06 22:11:16 <denkenz> yep?
Jan 06 22:11:47 <leiyu> Don't quite understand when u say: "Can you try substituting a macro / inline function that can extrat a max of 8 bits from a bitstream instead? ... still keep most of the advantages you list out above".
Jan 06 22:12:06 <leiyu> The advantage I try to achieve is to replace following code line 
Jan 06 22:12:18 <leiyu> ((pdu[0] & 0x3f) << 4) | ((pdu[1] >> 4) & 0xf);
Jan 06 22:12:42 <leiyu> with a simple function call: fieldx = unpackt(buf, offset, fieldx_len);
Jan 06 22:13:15 <leiyu> having logic like ((pdu[0] & 0x3f) << 4) | ((pdu[1] >> 4) & 0xf); at each field decoding can be error prone.
Jan 06 22:13:38 <denkenz> so make a function / macro for it, but don't go overboard
Jan 06 22:13:40 <leiyu> Understand your point that unpack function I have may not be easily inlined.
Jan 06 22:14:08 <denkenz> you can even design a simple macro that will unpack 8 bits at arbitrary offset
Jan 06 22:14:11 <leiyu> yes, that's where I try to understand what u mean of overboard. 
Jan 06 22:14:37 <denkenz> Or any bits <= 8 at arbitrary offset
Jan 06 22:15:29 <leiyu> If that is the case, either I need another macro to decode field size x (>=8, <=16) at any offset by invoking that macro, right? In order to avoid having that complicated logic in every decode place.
Jan 06 22:15:34 <leiyu> Will that suffice?
Jan 06 22:15:54 <denkenz> why do you need >= 8 <= 16?
Jan 06 22:16:00 <denkenz> I've only seen this for ids which are 16 bits
Jan 06 22:16:13 <denkenz> and that is a simple matter of calling unpack macro twice
Jan 06 22:19:01 <leiyu> yep.
Jan 06 22:19:17 <leiyu> Ok, will change that.
Jan 06 22:19:50 <leiyu> Another topic about "You also get automatic checking of the presence of the mandatory fields which you do not do right now and will repeat at least twice."
Jan 06 22:20:21 <leiyu> Right now, if you see the logic we have per CDMA SMS spec, the decoding is happening separately from checking the presence of the mandatory fields.
Jan 06 22:20:23 <denkenz> heh, I must really suck at writing :P
Jan 06 22:20:45 <denkenz> Yes, so in general I don't like that
Jan 06 22:20:52 <denkenz> you should just check for mandatory fields right then and there
Jan 06 22:20:55 <leiyu> Since whether a field is mandatory depending on what's the teleservice type,
Jan 06 22:20:57 <denkenz> and ignore anything that isn't valid
Jan 06 22:21:16 <denkenz> Are you confusing mandatory and conditional?
Jan 06 22:21:28 <leiyu> We thought about this quite a few times but see it is hard.
Jan 06 22:22:19 <leiyu> The way CDMA SMS PDU is structured is that it is just packed with many parameter records and sub-parameter record.
Jan 06 22:22:46 <leiyu> When decoding entire bit-stream (PDU), you just have to decode everything (or anything you currently support).
Jan 06 22:23:18 <denkenz> The CDMA SMS PDU looks so much like a MMS WSP pdu or an STK pdu its not funny ;)
Jan 06 22:23:30 <denkenz> And yes, conditional ones are tricky
Jan 06 22:23:37 <denkenz> But the plain mandatory ones you can enforce right away
Jan 06 22:23:39 <leiyu> Then, at the time of processing, based on the teleservice type, message id (submit/deliver/ack/...), only then can you determine whether a parameter/field is mandatory or not.
Jan 06 22:25:47 <leiyu> Per CDMA SMS spec, the mandatory ones is hard (even if possible) to be enforced right away.
Jan 06 22:25:55 <denkenz> Besides, don't you know the teleservice at that point? :)
Jan 06 22:26:13 <leiyu> CDMA SMS defines which ones are mandatory based on teleservice type, message id (submit/deliver/ack/....).
Jan 06 22:26:23 <leiyu> yes, you may not have all the info then.
Jan 06 22:26:35 <leiyu> Yes, that's a really weird way of defining message structure.
Jan 06 22:26:42 <leiyu> But, that's how they define that.
Jan 06 22:28:10 <leiyu> You may have teleservice info but may not have message id info.
Jan 06 22:32:58 <leiyu> denkenz: Got my last set of questions/comments?
Jan 06 22:33:12 <leiyu> "You may have teleservice info but may not have message id info."
Jan 06 22:50:12 <leiyu> denkenz: u there?
Jan 06 22:53:45 <denkenz> leiyu: Sorry, phone call ;)
Jan 06 22:53:53 <leiyu> no problem.
Jan 06 22:54:38 <denkenz> what's message id, section #?
Jan 06 22:55:04 <leiyu> section 4.5.1
Jan 06 22:56:42 <denkenz> err
Jan 06 22:56:50 <denkenz> how can you parse anything without knowing the message id?
Jan 06 22:56:57 <leiyu> I know.
Jan 06 22:57:17 <leiyu> That's where we are stuck with "blind parsing first", "then processing next".
Jan 06 22:58:10 <denkenz> no, don't do that
Jan 06 22:58:10 <denkenz> We do the same thing in STK
Jan 06 22:58:39 <leiyu> ??
Jan 06 22:58:42 <denkenz> we parse the first couple of data objects, then run the actual generalized parser
Jan 06 22:58:42 <denkenz> you can easily do the same
Jan 06 22:59:46 <denkenz> I'm assuming the objects have a defined order, at least for message id
Jan 06 22:59:46 <denkenz> and it looks like it is always mandatory
Jan 06 22:59:50 <leiyu> The problem also is that CDMA SMS PDU does not define which one parameter should come first, for example, it is possible that message ID sub-parameter record or teleservice ID parameter record comes at the last part.
Jan 06 22:59:59 <holtmann> They must define an order of the elements. Something like message id and teleservice type come first.
Jan 06 23:00:03 <leiyu> yes, it is always mandatory.
Jan 06 23:00:04 <holtmann> At least MMS does that.
Jan 06 23:00:10 <leiyu> No, they do not define order. 
Jan 06 23:00:21 <holtmann> That is utterly stupid.
Jan 06 23:00:27 <leiyu> If you see section 3.4.1.
Jan 06 23:00:38 <holtmann> I do not believe this. It would mean a huge performance hit for the networks.
Jan 06 23:00:44 <leiyu> message format is nothing but a set of parameter record.
Jan 06 23:00:54 <holtmann> Even MMS gets this right.
Jan 06 23:01:32 <leiyu> The thing is: implementation-wise network vendor/device vendor can build message in a specific order but since standard does not define a particular order, you just can not assume one.
Jan 06 23:03:01 <leiyu> Also see section 3.4.3.7, sub-parameter is also included in bearer data parameter record but no specific order defined.
Jan 06 23:03:19 <holtmann> Let me repeat; utterly stupid ;)
Jan 06 23:03:40 <leiyu> :-( Not something I can change.... 
Jan 06 23:04:29 <holtmann> It is a waste of memory in the message centers to dispatch these.
Jan 06 23:04:40 <leiyu> Actually, I checked other CDMA SMS implementation and that's how it has been done: parse all first, process next.
Jan 06 23:04:47 <holtmann> No idea how network operators can agree on such a stupid thing.
Jan 06 23:12:58 <denkenz> *catches up*
Jan 06 23:13:01 <denkenz> stupid link
Jan 06 23:13:15 <denkenz> Anyway, then run the iterator to find the message id
Jan 06 23:13:17 <denkenz> *then* parse
Jan 06 23:13:33 <denkenz> parsing without enforcement is really a bad idea
Jan 06 23:13:44 <leiyu> So, the parse/process will have to be after decoding all.
Jan 06 23:14:07 <denkenz> Not really, all you really care about is to run the iterator until you see the message id field
Jan 06 23:14:21 <denkenz> parse that one, then run the real parser
Jan 06 23:16:46 <leiyu> Can you point me to the decoding/parsing entry function within stkutil.c?
Jan 06 23:16:53 <leiyu> Like to see an example.
Jan 06 23:17:58 <denkenz> stk_command_new_from_pdu
Jan 06 23:18:06 <denkenz> STK has strict ordering
Jan 06 23:18:11 <denkenz> But the principles are the same
Jan 06 23:19:17 <leiyu> I like to know in detail the principles you would like us to follow. Sorry, I am bit slow. Especially on this iterator thing. ;-)
Jan 06 23:19:44 <leiyu> Decoding/parsing and checking for mandatory should be done in one shot?
Jan 06 23:19:54 <denkenz> yep
Jan 06 23:20:02 <denkenz> the iterator is basically a concept we use for TLVs
Jan 06 23:20:09 <denkenz> TLV = Tag Length Value
Jan 06 23:20:24 <denkenz> That is essentially what the CDMA spec does, in a sort of weird way
Jan 06 23:20:47 <leiyu> Do I have to use iterator? You also mentioned that "You also don't need to code the same exact loop multiple times. "
Jan 06 23:20:55 <leiyu> Where do I have the same loop twice?
Jan 06 23:21:22 <leiyu> Currently, the decode will decode into a structure which is similar to iterator, agree?
Jan 06 23:21:28 <leiyu> union of structure.
Jan 06 23:22:10 <denkenz> cdma_sms_p2p_decode and cdma_sms_decode_bearer_data
Jan 06 23:22:17 <denkenz> almost the same magic structure
Jan 06 23:22:34 <denkenz> and yes, the iterator essentially does the same thing
Jan 06 23:22:42 <denkenz> but way easier to follow
Jan 06 23:23:16 <leiyu> But you always need the switch-case, right? Seems that I need to understand more about iterator.
Jan 06 23:23:29 <leiyu> iterator harder for me to understand for now. :-)
Jan 06 23:23:59 <leiyu> Ok, I will not take more of your time and I will think about it myself and see how to go about it and then chat with you.
Jan 06 23:24:17 <denkenz> just look at the simple_tlv_iterator code in simutil.c
Jan 06 23:24:30 <denkenz> It is essentially the same thing you're doing but behind a proper API
Jan 06 23:24:43 <leiyu> Another thing, do you have preference of calling enums of CDMA_SMS_xxx or SMS_CDMA_XXX.
Jan 06 23:24:45 <denkenz> You can re-use it everywhere without hand-coding the same logic again and again
Jan 06 23:24:56 <leiyu> Thanks for your help. Will look into those.
Jan 06 23:25:05 <leiyu> I am calling CDMA_SMS_XXX crosss.
Jan 06 23:25:21 <leiyu> Of course, prefer not have to change it.
Jan 06 23:25:58 <denkenz> you call the atom cdma_sms
Jan 06 23:26:02 <denkenz> so that is fine 
Jan 06 23:26:11 <leiyu> Ok, I will stick with that.
Jan 06 23:26:35 <leiyu> Will re-work per our discussion and re-submit. Or else, I will come back with more questions. :-)
Jan 06 23:27:11 <denkenz> sure, that's what I'm here for ;)
**** ENDING LOGGING AT Fri Jan 07 02:59:58 2011