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

List:       kde-pim
Subject:    [Kde-pim] RFC: pimd
From:       Jakob Schroeter <js () camaya ! net>
Date:       2004-12-01 2:27:28
Message-ID: 200412010227.32942.js () camaya ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi,

about two weeks or so ago a discussion came up where some central `pim server' 
was mentioned, keeping calendar (and probably address book as well) data in 
memory only once instead of having it being loaded by every application.

I would really like to work on that and I'm even in the lucky position to have 
some influence on the decision whether I would have some time to do so 
(without any negative side effects ;).
So, first of all, is this something you would like to see in KDE? (v4 would be 
my goal here)

Generally, I see this as a kded module handing out the pim data via dcop/dbus.

Advantages:
- apps could ask for subsets of data (`gimme all events for 20/11/04')

- apps could ask for certain categories only (birthdays, events with alarms 
set, ...)

- loading of events that are not displayed could be delayed (on startup, 
korganizer only needs the events for the view the user used last)

- less memory consumption (loaded only once per kde session/user instead of 
once per application)

- apps would be able to drop events/addresses they no longer need to keep in 
memory

- apps could be asked to update their data in case another app commited a 
change

- updated data even could be pushed to apps asking for this service

- every app always has an up-to-date set of data (no sync of outdated events 
to the handheld, ...)

- non-kde apps could access kde pim data without build-time dependency

Maybe there are even more I don't see atm.


Disadvantages:
- dcop/dbus would add some latency

- since there would be no gui access, apps would be responsible for conflict 
resolution. however, shared widgets/functions could unify this.

- porting all the apps currently using libkcal & co. would need some effort, 
but maybe a wrapper library could provide the current interface and wrap it 
to dcop calls?

- kded modules are hard to debug I hear 

- I would need a lot of help from you guys

- ??? certainly much more


This is only a first list of thoughts. There is probably much more to 
consider. As a start:
- How does this fit into KDE's resources system? (Or the other way round)



What do you think?

cheers,
Jakob

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

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