Re: [PATCH 06/11] Made it possible to ask for status report via SendMessage method parameters. True=status report on, false=off.

[Marcel Holtmann <marcel@holtmann.org>]

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

Hi Inaky,

> > > > > > I don't like this being an argument to SendMessage(). I think it
> > > > > > needs to be exposed, but as a property instead. Is there a use case
> > > > > > for setting this per message? I think majority of current phones
> > > > > > either provide a global setting for this, or set it on by default.
> > > > >
> > > > > our idea is actually that every new SMS has its own object path for its
> > > > > lifetime. So we can have then properties easily on them.
> > > >
> > > > Sure, but there should still be a property in SmsManager to control
> > > > whether srr is to be set on outgoing messages.
> > > >
> > > > Another property in the actual SmsMessage (residing on its own object
> > > > path) could then indicate whether srr *was* set for that particular
> > > > message when it was sent.
> > > 
> > > I tend to disagree with that; by making it an SmsManager property, you
> > > are creating an API that is not reentrant. If more than one application
> > > is sending SMS's at the same time and they have different requirements
> > > wrt to status-reports, they would be trumping each other:
> > 
> > While you're 100% correct about a possible race condition, the reality is that 
> > nobody actually uses it this way.  It is just a setting buried somewhere in 
> > the Settings UI that the user maybe changes once in his lifetime.
> 
> If you are confident this will never be a problem then *shrug*; I am
> just not comfortable with generic unconstrained APIs that operate like
> that.

please keep in mind that we are on purpose not going to expose anything
just for the sake of having an API for it. The API must make sense from
an UI use case point of view. oFono is suppose to do all the heavy
lifting and this also means that we are not exposing every single detail
or possibility of GSM/UMTS.

I would even go one step further in this case and always request status
reports and if the user doesn't want them, then it can throw this kind
of information away.

So there might be cases where we are wrong in the first place, but that
is fine as well. This is a learning experience that we have to go
through to create proper APIs. This API design by committee is not
working out anyway. It just creates clutter and extra shim layers since
everything gets way too complicated. The idea is to have a really simple
API first and then only if needed introduce complexity.

Regards

Marcel