From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============2659391894833469657==" MIME-Version: 1.0 From: Denis Kenzior Subject: Re: [PATCH] sms: Add delay before submitting multiple SMS to modem Date: Thu, 23 Aug 2012 12:33:03 -0500 Message-ID: <5036694F.7030805@gmail.com> In-Reply-To: <50363D9B.80400@linux.intel.com> List-Id: To: ofono@ofono.org --===============2659391894833469657== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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, >> >> >> >>> 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 solutio= n. > 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 --===============2659391894833469657==--