Re: RFC 4833 / TimeZone by DHCP

[Dan Williams <dcbw redhat com>]

On Tue, 2007-12-04 at 08:46 +0100, Dominique Leuenberger wrote:
> Hello
> 
> >>> On 12/4/2007 at 2:08 AM, Dan Williams <dcbw redhat com> wrote:
> >> Or the international clock listens and makes the change since it knows
> >> how to do that.
> > 
> > Exactly; that's the ideal case.  I want the model to be pull _from_
> > NetworkManager provided information, not have NM push stuff out.
> > 
> 
> Well, that sounds actually like a very ideal cae. Is there somewhere already documented how any application can pull any information from NM? Is this interface ready? If so, I could start getting in touch with the 'International Clock' team for an implementation from this side. 

No, the interface isn't defined yet.  Comments and suggestions
welcome...  I currently envision that it would be a D-Bus interface of
any currently active Connection object.  However, Connection objects
aren't represented as first-class objects in NM yet, which we may wish
to do for this and other reasons.

Dan

> If the interface in NM is not defined yet, there is of course only little point in this. They could not implement anything working.
> 
> Thank you for your consideration; I like the way it's approached and I see a solution for the problem on the horizon.
> 
> Dominique
> 
> 
> 
> TMF is a global management and accounting outsourcing firm with 77 offices in 60 countries and over 2,000 professionals (2007). TMF is expanding rapidly throughout the world. Learn more about our unique network and our services and visit our website at www.tmf-group.com.
> 
> The information contained in this e-mail communication is confidential and solely intended for the person to whom it is addressed. If someone other than the intended recipient should receive or come into possession of this e-mail communication, he/she will not be entitled to read, disseminate, disclose or duplicate it. If you are not the intended recipient, you are requested to notify the sender and to destroy the original e-mail communication. 
> TMF is neither liable for the correct and complete transmission of the information contained in this e-mail communication nor for any delay in its receipt.  This footnote also confirms that this email message has been checked for the presence of computer viruses.
>