**** BEGIN LOGGING AT Sat Nov 27 02:59:58 2010
Nov 27 06:43:38 <Jeevaka> denkenz: hi
Nov 27 12:55:24 <demarchi> Jeevaka: around?
Nov 27 13:57:44 <Jeevaka> demarchi: yes
Nov 27 13:59:17 <denkenz> Jeevaka: pong
Nov 27 14:00:35 <Jeevaka> have you seen my proposal for VoiceUnconditional and Number property as part of EFcfis and EFcphs-cff?
Nov 27 14:08:44 <Jeevaka> denkenz: question is for you?
Nov 27 14:14:24 <denkenz> I think I'm fine with it
Nov 27 14:14:36 <denkenz> But the question is, how do you handle EFcfis and CACHED?
Nov 27 14:15:16 <denkenz> Also, you have EFcfis described in 51.011
Nov 27 14:15:32 <denkenz> So only using it for phase 3G is wrong
Nov 27 14:17:17 <Jeevaka> ok, I based my code on 3GPP 11.11
Nov 27 14:17:38 <Jeevaka> but as per 51.011, its also there
Nov 27 14:17:59 <denkenz> I suspect you will have to read the 3GPP one first, and if absent use CPHS
Nov 27 14:18:16 <denkenz> Or lookup EFust / EFsst
Nov 27 14:18:57 <Jeevaka> CPHS only in SIM and not in USIM
Nov 27 14:19:19 <Jeevaka> ok, I'll do that
Nov 27 14:19:52 <denkenz> And I'm not sure setting cached flag is good when reading EFcfis
Nov 27 14:20:17 <Jeevaka> Is it ok to have VoiceUnconditional with values "enabled" and "disabled", Number holding the call forwared number
Nov 27 14:20:21 <denkenz> That way you only have CFU, not the conditional CF entries
Nov 27 14:20:28 <Jeevaka> ok
Nov 27 14:20:56 <denkenz> The question is whether we can trust the SIM
Nov 27 14:21:10 <denkenz> If we can, then we can skip CFU query from the network
Nov 27 14:21:31 <denkenz> if not, then signaling the property and re-querying the network might be needed
Nov 27 14:21:52 <Jeevaka> its better to rely on network rather than SIM
Nov 27 14:22:21 <Jeevaka> if some phone doesn't update the SIM file, then we will be having issues
Nov 27 14:23:47 <denkenz> I agree, so it might be that behavior might need some tweaking
Nov 27 14:24:17 <Jeevaka> ok
Nov 27 14:24:23 <Jeevaka> Is it ok to have VoiceUnconditional with values "enabled" and "disabled", Number holding the call forwared number
Nov 27 14:24:56 <denkenz> see I think we shouldn't populate the property with the number from EFcfis at all
Nov 27 14:25:03 <denkenz> Since we'll be querying it from the network
Nov 27 14:25:24 <denkenz> I think we should write the EFcfis entry when setting it
Nov 27 14:25:47 <denkenz> And maybe introduce a ForwardingFlagOnSim or something
Nov 27 14:26:47 <Jeevaka> do you mean updating the SIM file even before network confirms the request?
Nov 27 14:27:22 <denkenz> No, the way we do it is to update it from the set query
Nov 27 14:27:32 <denkenz> That way we write the latest info
Nov 27 14:28:19 <Jeevaka> so, your idea is to have one property "ForwardingFlagOnSim" which will be updated based on the SIM information
Nov 27 14:28:53 <Jeevaka> Number will be updated based on network query
Nov 27 14:30:18 <denkenz> that is what I'm suggesting
Nov 27 14:30:35 <denkenz> I think trusting the sim is not good, and setting the cached flag isn't
Nov 27 14:31:06 <Jeevaka> yep, agree
Nov 27 14:31:16 <denkenz> The only tweak we can make is to 'temporarily' signal the VoiceUnconditional property based on EFcfis
Nov 27 14:31:23 <denkenz> But not set the cached flag
Nov 27 14:31:38 <Jeevaka> ok
Nov 27 14:31:45 <denkenz> That way the app might get an early hint of what the number is
Nov 27 14:32:52 <Jeevaka> I would like to have VoiceUnconditional and Number property separately. Whats ur opinion on this?
Nov 27 14:33:24 <denkenz> hm, why?
Nov 27 14:34:57 <Jeevaka> currently, in my code I have used property "VoiceUnconditional" and "VoiceUnconditionalStatus"
Nov 27 14:35:15 <Jeevaka> somwhat, confusing
Nov 27 14:35:31 <denkenz> In the end it is specifying the same call forwarding rule
Nov 27 14:35:50 <denkenz> And the query logic will figure this out
Nov 27 14:36:21 <denkenz> So if you read cfis, and you have the number set there, then signaling VoiceUnconditional and setting it to whatever is fine
Nov 27 14:36:30 <denkenz> Once GetProperties is called, you re-query from the network
Nov 27 14:36:45 <denkenz> if the number is different, you signal VoiceUnconditional again
Nov 27 14:37:16 <denkenz> And then write EFcfis back
Nov 27 14:37:27 <Jeevaka> currently, I'm using the VoiceUnconditionalStatus for cphs-cff case
Nov 27 14:38:00 <Jeevaka> cphs-cff case, number is not available
Nov 27 14:38:25 <denkenz> So for that case set the ForwardingFlagOnSim and don't signal the VoiceUnconditional
Nov 27 14:38:44 <denkenz> Once GetProperties is called, we query it from the network anyway
Nov 27 14:39:10 <Jeevaka> ok
Nov 27 14:39:18 <denkenz> The only usefulness of these files is to tell the user they can't receive calls
Nov 27 14:39:25 <denkenz> The actual number is pointless
Nov 27 14:39:27 <Jeevaka> yep
Nov 27 14:40:22 <Jeevaka>  correct me if I'm wrong, cphs-cff applies only to SIM and not USIM.
Nov 27 14:41:06 <denkenz> I don't think this is always true
Nov 27 14:41:20 <denkenz> ATT 3G USIMs come with EFcsp files
Nov 27 14:42:05 <Jeevaka> ok, so we need to read both the files in all cases
Nov 27 14:42:33 <denkenz> In general I prefer we stick to using 3GPP as preferred
Nov 27 14:42:41 <denkenz> I think we do the same for EFmbdn
Nov 27 14:43:07 <denkenz> And EFmwis
Nov 27 14:43:25 <Jeevaka> ok
Nov 27 14:44:07 <Jeevaka> I'll update the patch and resend it
Nov 27 14:45:07 <Jeevaka> I'm still not convinced with the call-volume registering after all the property update
Nov 27 14:45:43 <denkenz> heh
Nov 27 14:46:31 <Jeevaka> we are querying and updating the core which just updates the core with the values
Nov 27 14:47:32 <Jeevaka> after all this, we trigger the register which is not going to trigger property change
Nov 27 14:47:36 <demarchi> denkenz: i've created a patch for changing !ptr into ptr == NULL
Nov 27 14:47:55 <demarchi> denkenz: since we are being style-pedantic, i think it's worth applyin
Nov 27 14:48:03 <demarchi> what do you think?
Nov 27 14:48:04 <demarchi> http://codepad.org/JqyHjY5O
Nov 27 14:52:55 <demarchi> if it's worth applying, I can split it and double check
Nov 27 14:53:11 <demarchi> it was a patch automatically generated with coccinelle
Nov 27 14:59:43 <denkenz> demarchi: Go for it, but split it up according to toplevel directory boundaries
Nov 27 15:00:00 <demarchi> denkenz: ok...
Nov 27 15:00:13 <demarchi> denkenz: do i add a rule to coding-style.txt?
Nov 27 15:00:18 <denkenz> Can you also update the doc/coding-style.txt to mention ....
Nov 27 15:00:23 <denkenz> yes ;)
Nov 27 15:00:37 <demarchi> another rule that might be good to add is about patches
Nov 27 15:00:47 <denkenz> Jeevaka: So call-volume is weird because of hfp
Nov 27 15:00:52 <demarchi> that have to be split in a per-directory basis
Nov 27 15:00:58 <denkenz> Jeevaka: That's why it uses unconventional set methods
Nov 27 15:01:04 <denkenz> demarchi: Yep, good idea
Nov 27 15:02:08 <denkenz> Jeevaka: And I also do not necessarily want the properties to be signaled with the defaults actually
Nov 27 15:04:55 <Jeevaka> ok
Nov 27 15:11:08 <Jeevaka> demarchi: if its possible, could you please take care of no new line between an allocation and NULL checking
Nov 27 15:18:17 <demarchi> Jeevaka: yes, i can to that
Nov 27 15:18:30 <demarchi> Jeevaka: but this is another commit, another coccinelle script
Nov 27 15:18:52 <demarchi> Jeevaka: are all the allocations done with g_try_malloc0 ?
Nov 27 15:19:07 <demarchi> sorry... g_try_new0
Nov 27 15:19:57 <demarchi> ahn... no, there is g_try_new0 and g_try_malloc
Nov 27 15:20:04 <demarchi> are ther any others?
Nov 27 15:21:09 <Jeevaka> for eg:dbus_message_new_method_return
**** BEGIN LOGGING AT Sat Nov 27 18:44:20 2010
**** ENDING LOGGING AT Sun Nov 28 02:59:57 2010