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

List:       kde-pim
Subject:    How this all fits in Mike's scheme
From:       "Adriaan de Groot" <adridg () sci ! kun ! nl>
Date:       2001-06-14 22:50:06
[Download RAW message or body]


Last one for the night: it's past midnight.

I really think that the local binary store is important, since I believe we 
need a way to restore a device in the case of a catastrophic crash, *and* not 
all the data on a device need be related to a KDE app (consider my Tyrrany 
high scores). 

We might get a semi-smart daemon by making conduits plugins in the daemon, 
and adding a generic binary backup conduit to the daemon for unknown data 
sources. As long as each conduit can guarantee that it can restore the 
device's data in the case of failure, we're OK. So an addressbook conduit for 
a Pilot would have to backup all addresses -- say in kab -- but *also* the 
addressbook preferences and layout set in the pilot. It might be complicated 
to delegate repsonsibliity for each bit in the deivce properly.

Anyway, I'd like to tie into Mike's idea of a central PIM server. I'm going 
to stick to my terminology still. Conduits now don't talk to any old KDE 
application, they talk to the KDE PIM server [there may be exceptions! my 
Hearts stats, which I may want to keep consistent between my Pilot and KDE, 
needn't go in the PIM server (though they might, if we decide that high 
scores are PI)]. 

1) Conduits talk to the sync manager by DCOP to deliver status reports. This 
wasn't illustrated in the previous picture, but should have been.

2) Conduits read the local binary store directly.

3) All (?) the conduits talk to the server with DCOP and XML -- the XML 
mostly so that the interface to the server is completely general and easily 
extensible.

4) The PIM server saves the data in some local store. eks might extend this 
to storing the data in various places, perhaps even publishing it on the 
internet.

5) Other (application) conduits are used to communicate from a KDE app to the 
PIM server. [Remember, a conduit is like a pipe with a filter in the middle. 
One end speaks XML, the other end speaks something weird and locally 
proprietary.] 

Although I've drawn the application conduit as a seperate part, it might 
easily be integrated into the application.

So this picture is actually a slice of Mike's drawing. Hm.

NOTES:

Now PI applications are concerned only with viewing and modifying, not with 
storing, data. KPilot - the viewer - becomes an app that reads Pilot 
databases and displays them, and since Pilot databases only become PI thorugh 
interpreting them in one particular way, KPilot is no longer a PI 
application! KOrganizer is, though, as is the Pilot daemon.

We need new mimetypes! (Reminds me of a Primus song, on Frizzle Fry. You can 
tell it's getting late.) No, I mean ServiceTypes. I'd suggest

daemon/pilot
daemon/phone

if we can do subtyping like that in .desktop files. Then we have

conduit/pilot

for all the conduits able to translate pilot local binary store to PIM. These 
would all have to run sometime. Application conduits don't need a 
servicetype, I don't think.


Good night, all.

-- 
To UNSUBSCRIBE from the KPilot mailing list, send a message
with subject "unsubscribe kpilot-list" and an empty body
to majordomo@slac.com.

Adriaan de Groot -- KPilot 4.2 (for KDE 2.2) maintainer
http://www.cs.kun.nl/~adridg/kpilot/
["kpilot-pim-arch.png" (image/png)]

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