Re: [PATCH] sms: Add delay before submitting multiple SMS to modem

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]

Hi Guillaume,

On 08/23/2012 09:26 AM, Guillaume Zajac wrote:
> Hi Denis,
>
> On 23/08/2012 15:48, Denis Kenzior wrote:
>> Hi Guillaume,
>>
>> <snip>
>>
>>> Unfortunately I come to the conclusion that if I want to send one same
>>> SMS to 3/4/5/... recipients with an application using oFono middleware,
>>> I will not be able to send them through the same RRC channel, unless I
>>> queue them offline.
>>>
>>
>> If such a feature is important, then you do have a point. However,
>> implementing _anything_ by introducing an arbitrary delay is simply
>> wrong. I believe they teach the reasons for that in Operating Systems
>> 101. You are introducing a race condition that will break things at
>> the most inopportune time.
>
> I agree that it is not the most elegant/cleanest solution.
>

Then please refrain from sending patches which contain 'not the most 
elegant/cleanest' solution in the future.  oFono has a very high 
standard of quality, and the standard is even higher in the core than 
the driver code.

You are better off starting a discussion on IRC or describing the 
problem in detail on the mailing list asking for possible solutions.

>>
>> If we really require multi-recipient SMS to go on the same RRC
>> channel, then the best way to do so would be to introduce a new API
>> specifically for this use case.
>
> Having a new API for multi-recipient SMS would be indeed the best solution.
> With current implementation the test is passing with multi-segment SMS
> using script but GCF test description is mentioning 3 different SMS.
> During device certification (with applications), the tester will try to
> send an SMS to 3 recipients but it will fail.
> Another solution would be to remove multi-SMS support from the PICS.

Our current goal is just the baseline.  That means if we're missing a 
feature, then we need to note that down and continue on.

This is where the TODO file comes in.  If you see features that are 
missing, then send a patch to the TODO file describing the feature and 
the preferred approach (after the relevant discussions on IRC/mailing 
list).  The feature priority assignment / implementation can then 
proceed with the well-established workflow.

Regards,
-Denis