Re: [evolution-patches] (no subject)



Le mercredi 16 novembre 2005 à 22:18 -0500, Christopher Aillon a écrit :
> 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 à 16:34 -0500, David Malcolm a écrit :
> >>     
> >>> 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.

Well, our own tools are already doing more than NetworkManager, so we
don't see any pro to switch to NW. 

I don't want to transform with thread in a "my tools are better than
your tools". 

I don't care about NW vs drakxtools/net_applet, all I'm saying is we
should try to hardcode dependency when they are not really needed.

-- 
Frederic Crozat <fcrozat mandriva com>
Mandriva




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]