[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: RFC #N:  KPIM Data Access
From:       Chris Lee <lee () azsites ! com>
Date:       2002-01-08 20:43:03
[Download RAW message or body]

I know I'll get flamed for this :)

But doesn't this sound very similar to what the GNOME guys are doing
with Evolution? IIRC, their "wombat" backend is doing exactly this.
Maybe someone should take a look at their code?

-clee
On Tue, 2002-01-08 at 13:30, Waldo Bastian wrote:
> On Tuesday 08 January 2002 11:31 am, Nick Papadonis wrote:
> > 3.1 General Data Access
> > There should be a common methods for ALL applications to access PIM data.
> > I envision the use of a lightweight client/server relational
> > database.
> >
> > DATABASE SERVER PROCESS <----> DATABASE CLIENT PROCESS
> >
> > Let the DB server be present on the machine running PIM applications.
> > Each application uses the appropriate DB client methods to access
> > data in the datastore.
> 
> I wouldn't tie myself to a specific data-storage method. I would use something 
> like:
> 
>  DATABASE STORAGE  --+                  +-->KORG_DATA_PXY
>                      |                  |
>                      +-->KPIM_DATA_PXY--+-->KNOTES_DATA_PXY
>                      |                  |
>  FILE BASED STORAGE -+                  +-->KMAIL_DATA_PXY
>  
> The proxies would run in a single process (per desktop) and be accessed by the 
> various applications via IPC (dcop).
> 
> This gives you greater flexibility because you can now get your data from e.g. 
> a LDAP server or some kind of proprietary server by plugging in a new
> storage method.
> 
> > When using a database for accessing and
> > storing data, many uncertainties and debug efforts are elimanted from
> > development.
> 
> With the above approach you will eliminate many uncertainties (mostly the 
> parts that involve keeping your data consistent when having multpiple 
> applications that access/modify it) due to the partly centralized approach.
> E.g. for the single desktop case you can use a simple flat file format as 
> storage to start with. Later on you can then provide more advanced storage 
> mechanisms that work better in the light of concurrent access from multiple
> desktops.
> 
> Once you have the proxies finished and the simple file based storage in place, 
> applications can start using it and in the meantime you can work on more
> advanced storage methods without holding up application development.
> 
> Cheers,
> Waldo
> 
>  
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
> 


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]