ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Fri, 2014-05-02 at 08:38 -0700, Alex Chiang wrote:

> On Thu, May 1, 2014 at 2:16 PM, Ted Gould <ted@xxxxxxxxxx> wrote:
> > > On Thu, 2014-05-01 at 17:01 -0400, Chris Wayne wrote:
> > > Also a carrier may want to enable/disable certain services (think 4g
> > > tethering) for example,
> >
> >
> > This seems like it'd be better handled with a DConf key for that service.
> > It's also allow it to be more dynamic.
> 
> As a real world example of the services we might want to disable:
> 
> - mediascanner service
> - urldispatcher
> - mtp-server


Hmm, as the upstream for URL Dispatcher that makes me a bit nervous.
Why?

So I'm not saying that you shouldn't be able to disable them, but that
disabling them should be part of the upstream config. i.e. if needed URL
Dispatcher should have a supported and tested mechanism for being turned
off. We should also support giving an appropriate error in
liburl-dispatcher based on that.

<snip, not sure of the Android solution, but you seem happy there>

> I guess my question is, is patching each individual service to look
> for a dconf key to decide whether to start or not the better
> architectural decision than disabling them via the init system?
> 
> Looking for guidance here.
> 
> Thanks.
> 
> ps, can you explain how the dconf mechanism is more dynamic?


DConf, as an example (it's not the end all be all), provides layering of
the settings. So if you set one key in the list of settings the defaults
for the others still come through. Where as if I have 10 environment
variables set in a section of an Upstart job you make a copy of all of
them, and I can't change them at all anymore.

Changing an Upstart job can also have far reaching consequences as the
name and signals for that job can effect how other jobs startup. So
simply causing a job to not start by stopping it in pre-start could
cause other jobs to not start or signals to get sent. It's a really big
stick. I don't think we want to measure and test changes to all those
interfaces, it reduces our flexibility for solutions if we constrain
those being constant.

In summary, I do think that we should have a way to disable, replace or
configure the services as needed for the OEMs and carriers, but I don't
think we should encouraging working around the services using the init
system. It should be something pushed into the services configurations
so it can get unit tests and awareness for the developers of the
service.

Ted

Attachment: signature.asc
Description: This is a digitally signed message part