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

List:       kde-pim
Subject:    Re: How this all fits in Mike's scheme
From:       Olaf Zanger <olaf.zanger () gmx ! net>
Date:       2001-06-15 15:10:01
[Download RAW message or body]

> 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)].
that's about where my thinking differs. i don't think too much in a specialized
"kde-pim-server" but in a generalized "syncing structure" AND "data storage" for ALL
(kde-)apps.

the reason:
it is not only PDAs, Mobile Phones and laptop but about every device that is not
online for the whole working time (maybe someday that is not a question anymore :-¦
but we are far off this date). 

so data are stored at places like:
[1] Mobile Phone,
[2] PDA,
[3] Workstation at Work,
[4] Server at SOHO (remote working),
[5] Server at Work,
[6] Desktop at home,

eks is supposed to hit all that in an online-intenet-appliance structure. 
 * the eks-system therefor is only for the online-work time. that is the reason why i
search for a system-structure that can access all types of data transparently via
conduits (pst-file2xml, pgsql2xml, ...). 
 * a ksync-system would have to deal with the syncing for the offline-work time. the
ksync-system would have to deal with the "which-data", "how-often", "where-to" and so
on.

so in the middle of all this would have to be a information-broker that has conduits
to the data storage and to the apps. 

this information-broker would be a data-type translation deamon. in the easiest case
it would tell the asking app that the data are in kword-xml format. the app might
have a import filter for that and load the stuff through information-broker without
any changes

since all koffice documents are saved in xml there have to be filters for
xml-msoffice anyway, so why not doing this straight in an information broker.

the same applies to kandy, kpilot, korganizer and all the others. 

this information-broker would allow a app to ask e.g. 

Q1: please can i have a list of all data that have been changed since 2001-04-02?
A1: information-broker searches the database and the filesystem with koffice files.

Q2: kpilot: please information-broker give me all text documents that are marked for
syncing to pda in palm-pilot format?
A2: information-broker searches on [1-6] depending on actual access to the
data-repository and the users wishes

Q3: korganizer: i want all events interesting for the business trip to spain for from
the spanish holiday calendar, the users business and privat events, and workgroup
events in my format. after that kpilot syncs them to the pda.
A3: information-broker accesses kde-spain holidays and/or a UDDI/XML-RPC repository.
the user business events come from the server, the privat events from the soho-server
the.

Q4: sync all beatles mp3 from the home-gateway to the pda?
A4: well easy :-)

well, crazy? hopefully not. so suddenly this information-broker is the "kontroller"
or "keeper" (and part of it does the business of the "kde-pim-server"

now the big thing is:
keep it simple
keep it easy to extend with new conduits (kio-slave like system)
it has to grow with the current kde-work
apps might keep some legacy abilites

please comment

> 
> 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/
> 
>   -------------------------------------------------------------------------------------
>                           Name: kpilot-pim-arch.png
>    kpilot-pim-arch.png    Type: PNG Image (image/png)
>                       Encoding: base64

-- 
Dipl.-Ing. (FH) Olaf Marc Zanger
Lorrainestrasse 23
3013 Bern / Switzerland
Mob: +41-76-572 9782

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