Re: [evolution-patches] (no subject)

[Christopher Aillon <caillon redhat com>]

On 11/16/2005 07:24 PM, David Malcolm wrote:
> On Wed, 2005-11-16 at 09:41 +0100, Frederic Crozat wrote:
>   
> > Le mardi 15 novembre 2005 �6:34 -0500, David Malcolm a �it :
> >     
> > > On Tue, 2005-11-15 at 16:00 +0530, Shreyas Sriniavasan wrote:
> > >       
> > > > Hey,
> > > >
> > > > Attaching the first few patches which dwell into Network Manager 
> > > > support for Evolution. Things which work in these patches
> > > >
> > > > 1) Evolution goes offline automagically if the network goes down. 
> > > > 2) Evolution goes online automagically if the network comes up and
> > > > syncs 
> > > > up mail, contacts whatever.
> > > > 3) If the network goes down when a sync is happening then evolution
> > > > cancels the event and goes offline
> > > >
> > > > Things to be done 
> > > >
> > > > 1) Journalling: Although i havent tested this thoroughly my code
> > > > intution 
> > > > says that if some operation are done and then network goes down and
> > > > evolution goes offline then these operations are not journalled and
> > > > re-played. Ofcourse the operations which happen after evolution goes
> > > > offline are journalled anyway and replayed later.
> > > >
> > > > 2) Good UI support: Right now the only Ui which depicts that evolution 
> > > > is offline is tiny weeny icon at the bottom of the screen. When we move 
> > > > to a state where evolution can transiently disconnect and re-connect
> > > > depending on the network, I personally would like to have Evolution
> > > > (Disconnected) on the Title bar. 
> > > >
> > > > 3) Paranoid conditions checking: 
> > > > i)  Should we allow users to switch from offline to online when the
> > > > network is down ?
> > > > ii) Should we allow users to start in online when the network is down ?
> > > >
> > > > I havent addressed these issues due to acute shortage of hacking time
> > > > before the next release. I have tested the code decently ( not
> > > > perfectly) and it *just works* (TM).
> > > >
> > > > Cheers,
> > > > Shreyas
> > > >         
> > > I've got a feeling that NetworkManager's dbus interface doesn't have an
> > > API guarantee at the moment.
> > >
> > > I just chatted to one of the lead coders on NetworkManager (Chris
> > > Aillon) and he thinks it makes more sense for applications to use the
> > > GLib bindings to NetworkManager, rather than the underlying DBus
> > > calls.  
> > >
> > > Here's the GLib NM API:
> > >
> > > http://cvs.gnome.org/viewcvs/NetworkManager/gnome/libnm_glib/libnm_glib.h?view=markup
> > >
> > > And here's an example of using that API to monitor changes in networking state:
> > >
> > > http://cvs.gnome.org/viewcvs/NetworkManager/test/libnm_glib_test.c?view=markup
> > >       
> > I'm not a big fan of that : it means it will requires network manager
> > library even for people / distributions not using / shipping Network
> > Manager. Using d-bus calls directly would allow distributions not
> > shipping Network Manager to still send the correct d-bus event with
> > their own network layer.
> >     
Given NetworkManager's popularity and rave reviews, distributions would 
be rather silly to not ship it.  Additionally, NetworkManager is 
intended to become part of GNOME.  I have been meaning to propose it for 
inclusion into 2.14.  Distributions which ship GNOME into the future 
*should* be shipping NetworkManager.

> In which case, make the choice of network detection system (or none) be
> a configure-time option, and have all usage of this go through a small
> wrapper API that uses whichever backend that the build is configured
> with.  Who's to say that any arbitrary person's/distribution's network
> management layer uses dbus?  dbus is an implementation detail of
> NetworkManager, not the intended application-level API.
>
>
>