RE: Patch: Added missing DCS handling in stkutil and stk Description
Hi Denis, Andrzej, Actually the spec is deviating from the intended purpose of the Text data object (which should contain Text), so handling it specifically is actually better. I have incorported the comments as part of the Patch stk and stkutil changes for Send USSD proactive command. As per your comments, I have also grouped the Send USSD proactive command into 2 compilable patches [PATCH 1/2] Internal and Driver API changes for Send USSD proactive command and [PATCH 2/2] stk and stkutil changes for Send USSD proactive command. Thanks and Regards, Jeevaka Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Patch: Added missing DCS handling in stkutil and stk Description
Hi Jeevaka, On 09/02/2010 08:59 PM, Jeevaka Prabu Badrappan wrote: Hi Andrzej, There are two cases: * Get Inkey/Get Input, where the answer is actual text, in this case the dcs can be determined automatically, * Send USSD where we're sending the 8.15 Text string but the contents don't actually have to contain a string, it may be any data that the network sends us. So to me it makes more sense to handle this using a separate structure like you did in your original patch, which contains len, dcs and contents. Yes, I undestand for the Get Inkey/Get Input, dcs is determined automatically. Currently, we are providing one function for building each data object specificed in 3GPP specification. If we provide a new structure, then we need to provide a new function for building the text string data object. This will result in having 2 build_dataobj_text( existing one for handling Get Inkey and Get Input) and build_dataobj_ussdtext(new one for handling the section 8.15), I agree with Andrew completely here. In effect your modifications to build_dataobj_text are doing this anyway. You're also forcing the Display Text, Get Input, Get Inkey, etc objects to care about details of USSD, which they really shouldn't. The code will be much simpler to follow if we use a different structure for this particular case. which is deviating from the existing ones. If we extend the existing structure and add generalised handling which is done now in this patch, we won't be deviating from the existing things. Actually the spec is deviating from the intended purpose of the Text data object (which should contain Text), so handling it specifically is actually better. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Patch: Added missing DCS handling in stkutil and stk Description
Hi, The following patch Added missing DCS handling in stkutil and stk handles the missing dcs case as: As per 3GPP TS 31.111 section 8.15 Text string structure requires dcs and text string to be sent. Current stkutil function and data structure is missing the dcs information. In this patch, we handle the case where dcs will be a value other than -1, yesno and packed values are false. This text string structure is used in Terminal response of Get Inkey, Get Input and Send USSD. Regards, jeevaka Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Patch: Added missing DCS handling in stkutil and stk Description
Hi Jeevaka, On 2 September 2010 16:16, jeevaka.badrap...@elektrobit.com wrote: The following patch Added missing DCS handling in stkutil and stk handles the missing dcs case as: As per 3GPP TS 31.111 section 8.15 Text string structure requires dcs and text string to be sent. Current stkutil function and data structure is missing the dcs information. In this patch, we handle the case where dcs will be a value other than -1, yesno and packed values are false. This text string structure is used in Terminal response of Get Inkey, Get Input and Send USSD. There are two cases: * Get Inkey/Get Input, where the answer is actual text, in this case the dcs can be determined automatically, * Send USSD where we're sending the 8.15 Text string but the contents don't actually have to contain a string, it may be any data that the network sends us. So to me it makes more sense to handle this using a separate structure like you did in your original patch, which contains len, dcs and contents. Best regards ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Patch: Added missing DCS handling in stkutil and stk Description
Hi Andrzej, There are two cases: * Get Inkey/Get Input, where the answer is actual text, in this case the dcs can be determined automatically, * Send USSD where we're sending the 8.15 Text string but the contents don't actually have to contain a string, it may be any data that the network sends us. So to me it makes more sense to handle this using a separate structure like you did in your original patch, which contains len, dcs and contents. Yes, I undestand for the Get Inkey/Get Input, dcs is determined automatically. Currently, we are providing one function for building each data object specificed in 3GPP specification. If we provide a new structure, then we need to provide a new function for building the text string data object. This will result in having 2 build_dataobj_text( existing one for handling Get Inkey and Get Input) and build_dataobj_ussdtext(new one for handling the section 8.15), which is deviating from the existing ones. If we extend the existing structure and add generalised handling which is done now in this patch, we won't be deviating from the existing things. Regards, jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
