Re: [PATCH 0/4 v2] Network Time plugin

[Marcel Holtmann <marcel@holtmann.org>]

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

Hi Remi,

> > So the idea of having an oFono D-Bus API to export time information is
> > just wrong from my point of view. The plugin inside oFono should tell
> > the time daemon about this.
> 
> That would be race-prone by design. For all we know, the time daemon might be 
> started after oFono (or restarted). It's pretty basic design to have a getter 
> and a change signal for any kind of value.

there is no race here. The timed plugin inside oFono can just keep the
time and only send it out when timed starts. You can easily monitor
deamons lifetime with D-Bus.

> Besides, I find hard-coding The One time daemon in the oFono plugin rather 
> silly. It's really nothing but an arbitrary design limitation that would be 
> overcome with a clean D-Bus API like we proposed several times.

It is a plugin that monitors the existence of such a daemon. So we can
have multiple plugins for each daemon. And we can even have them all
active at the same time. So where do you see a problem here?

> > And not the time daemon go out and bother
> > with additional sources etc.
> 
> Last time I checked, NTP clients "go out and bother" to ask the configured NTP 
> server, not the other way around. I fail to see reason why oFono should work 
> the other way around. I do see several reasons why it should not.

You need to tell NTP client (or the ntpd running) the time servers to
use. Check how we do that in ConnMan. we tell ntpd about time servers
and not the other way around.

> > And if you take the normalized time based on a monotonic clock, such a
> > plugin that just send a D-Bus message to a time daemon is actually a lot
> > simpler than exposing a full blown D-Bus interface.
> 
> It's very marginally simpler: one signal against one signal plus one getter 
> that will share much marshalling code with the signal. But that's irrelevant. 
> It actually works. The sole signal design is broken.

I was talking about a method call to timed and not a signal.

> > So the plugin just has to store the normalized time in memory. And if a
> > time daemon is present, then send out an update if needed, otherwise
> > don't bother.
> 
> Oh? That would actualy be far more complicated, as the plugin would then need 
> to track down the presence of the time daemon. I see some contradiction here.

And that is a problem with D-Bus how? With g_dbus_add_service_watch this
is dead simple actually. Simpler than providing a D-Bus interface.

Regards

Marcel