This series of patches introduces the network time part of the NITZ feature
as outlined in 3GPP spec 22.042. The Network Time plugin has two DBUS
interfaces for client applications: notification signal and polling method
call. The time information consists of three dictionary entries: 1) tim
Hi,
Could someone review this patch. It has been waiting for review a while
now. Thanks.
-Antti
On Fri, 2010-12-10 at 09:53 +0200, Antti Paila wrote:
> This series of patches introduces the network time part of the NITZ feature
> as outlined in 3GPP spec 22.042. The Network Time plugin has t
Hi Antti,
please do not top-post on this mailing list.
> Could someone review this patch. It has been waiting for review a while
> now. Thanks.
> > This series of patches introduces the network time part of the NITZ feature
> > as outlined in 3GPP spec 22.042. The Network Time plugin has two
Hi Marcel,
2010/12/21 Marcel Holtmann :
> I am still saying that the plugin should monitor the presence of timed
> and then just send a D-Bus message to timed. That saves us the problem
> with the timestamping.
There is no problem. If you still think there is a problem, you need
to continue the p
Hi Aki,
> > I am still saying that the plugin should monitor the presence of timed
> > and then just send a D-Bus message to timed. That saves us the problem
> > with the timestamping.
>
> There is no problem. If you still think there is a problem, you need
> to continue the previous thread on th
On Tuesday 21 December 2010 17:54:53 ext Aki Niemi, you wrote:
> It might make sense in some platforms,
> especially those that don't have a working monotonic clock...
That's a stupid requirement. Without a working clock, you can't get things
like poll(), select() or nanosleep() to work. So glib
Hi Rémi,
2010/12/21 Rémi Denis-Courmont :
> On Tuesday 21 December 2010 17:54:53 ext Aki Niemi, you wrote:
>> It might make sense in some platforms,
>> especially those that don't have a working monotonic clock...
>
> That's a stupid requirement. Without a working clock, you can't get things
> li
Hi Marcel,
2010/12/21 Marcel Holtmann :
> true, but as long as you guys are proposing an official org.ofono API it
> has to fit in a general context of oFono.
We can stuff this under meego.com instead, no problem.
> So that got fixed. Is this really enough for you guys to just normalize
> the va
Hi Aki,
> There is no problem. If you still think there is a problem, you need
> to continue the previous thread on this subject and prove your point.
>
> > And in case timed is not running it should just
> > set the current time directly.
>
> You're welcome to write such a plugin -- this is why
On Thursday 23 December 2010 04:44:52 ext Marcel Holtmann, you wrote:
> 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,
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 (o
This discussion is completely ridiculous at this point.
On Monday 03 January 2011 22:47:36 ext Marcel Holtmann, you wrote:
> > > 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
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
Hi Marcel,
On Tue, 2011-01-04 at 01:41 -0800, ext Marcel Holtmann wrote:
> > But then it is far simpler to have a D-Bus getter and a D-Bus signal by any
> > sane measure of complexity.
>
> So you did consider the complexity on both sides, ofonod and timed? And
> not just looked at one side of pi
Hi Aki,
> > > But then it is far simpler to have a D-Bus getter and a D-Bus signal by
> > > any
> > > sane measure of complexity.
> >
> > So you did consider the complexity on both sides, ofonod and timed? And
> > not just looked at one side of picture?
>
> Timed also needs to follow the regis
On Tuesday 04 January 2011 23:49:30 ext Marcel Holtmann, you wrote:
> Hi Aki,
>
> > > > But then it is far simpler to have a D-Bus getter and a D-Bus signal
> > > > by any sane measure of complexity.
> > >
> > > So you did consider the complexity on both sides, ofonod and timed? And
> > > not jus
On Wednesday 05 January 2011 10:29:40 ext Rémi Denis-Courmont, you wrote:
> There are some ambiguities though, for instance Honolulu and Unalaska have
> the same offset to UTC (in winter), same country code but are in different
> time zones. Note that this is the only case I know, and it only affec
Hi Marcel,
On Tue, 2011-01-04 at 13:49 -0800, ext Marcel Holtmann wrote:
> Hi Aki,
>
> > > > But then it is far simpler to have a D-Bus getter and a D-Bus signal by
> > > > any
> > > > sane measure of complexity.
> > >
> > > So you did consider the complexity on both sides, ofonod and timed? A
Hi Antti,
> > > > > But then it is far simpler to have a D-Bus getter and a D-Bus signal
> > > > > by any
> > > > > sane measure of complexity.
> > > >
> > > > So you did consider the complexity on both sides, ofonod and timed? And
> > > > not just looked at one side of picture?
> > >
> > > Ti
On Friday 07 January 2011 23:05:31 ext Marcel Holtmann, you wrote:
> I don't even like the fact that we imported it in ConnMan. That might
> have been a mistake actually. I really prefer to have that on the
> filesystem and we just mmap() it. And it is up to the distribution to
> provide such a fil
20 matches
Mail list logo
