Re: [Evolution-hackers] Re: ESource, backends
- From: Chris Toshok <toshok ximian com>
- To: Ettore Perazzoli <ettore ximian com>
- Cc: JP Rosevear <jpr ximian com>, Rodrigo Moya <rodrigo ximian com>, Hans Petter Jansson <hpj ximian com>, evolution-hackers lists ximian com
- Subject: Re: [Evolution-hackers] Re: ESource, backends
- Date: 17 Nov 2003 11:09:02 -0800
On Mon, 2003-11-17 at 11:02, Ettore Perazzoli wrote:
> On Mon, 2003-11-17 at 14:00, JP Rosevear wrote:
> > On Mon, 2003-11-17 at 13:49, Ettore Perazzoli wrote:
> > > On Mon, 2003-11-17 at 13:30, JP Rosevear wrote:
> > > > I prefer the serialized source solution, because it is possible to open
> > > > ad hoc calendars for temporary purposes. Could the gconf key just be a
> > > > named property on the source?
> > >
> > > I guess it could, but then you have a consistency problem... I.e. you
> > > have to make sure that the serialized XML always contains the right
> > > GConf path.
> > I guess - but you will need both the UID and the gconf key won't you?
> > Since the source will be in a gconf list.
I was thinking that the GConf key would be added by the underlying
library (libebook, libecal) before serializing it and sending it over to
the wombat. So we don't have much of a synchronization problem (we
aren't storing the key inside the xml we store in gconf.)
And we can always add the key to the xml blobs we serialize across.
It's just that the ad-hoc ones won't contain a uid (or contain an empty
string for the uid.. something). The backend can be made pretty simple
and always listen for gconf changes - it just won't ever receive any
that match the ad-hoc sources.
] [Thread Prev