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

List:       kde-pim
Subject:    information broker infrasturcture RFC
From:       Olaf Zanger <olaf.zanger () gmx ! net>
Date:       2001-06-16 1:51:00
[Download RAW message or body]

Dies ist eine mehrteilige Nachricht im MIME-Format.

hi there,

mike, adriaan and me started a discussion about the future of kpilot and pim-data
handling yesturday (well day before yesturday actually :-).

i'm comming not out of the established kde-pim team but bring some dbms and
www-app-server know-how and thinking with me (eks is the product of it)

since we found that our concerns all have to do with data infrastructure we discussed
about it. there are two sides of the cake. 
1. get right into it
2. dream big, plan well, work hard and get what you want.

since my first ps-document was really a first try and not very informative after all
i updated my view with the kde-pim discussion and came to this result. (i can the
clearer now 2.3 has come ... :-)

on the search for a refined infrastructure i came to the point that 
1. Manually starting syncing of PDAs and Laptops is just a speacial case of holding a
DBMS and a web-site in sync of local files like .kab, .kword, iCal, vCal, .na2, .pst
and other de-facto standards
2. XML is a great way to describe data on a very low abstraction layer
3. there is already a effort to put most of koffice data in xml anyway
4. in larger environments there is no way around a server or even a DBMS.

so some explanation to the ib-system-layout-0.0.3.pdf:
data matching (dm): is the action to match e.g. dbms-field "name" with kab-field
"last name" or kab-field "post-code" with palm-field "pcode"

conduits: data translators from or to xml and holders of storage-access information
(e.g. /home/office/kword or a connection string "eks@sino:5432 office")
 * a conduit in cl1 to kword-xml file format would actually do exactly nothing but
provide pathnames to kword-save paths (which would be set up in kconfigure), a
special path would be the one that comes from the file-selection-box.
 * there might be conduits not using xml-layer for faster access. but only the the
data storage with conduits in cl1 to xml-layer provides cross-sync capability and
full text indexing capability.

data transformation sets (dts): is a file that describes which fields to use in data
matching. (xml-format)

sync: as noted above sync apps would allow one or more of these tasks
1. sync PDAs manually (as kpilot does it)
2. visually editing and deploying dts files (see above "data matching").
3. setup of online syncing (e.g. local kab file with ldap or DBMS)

xml-layer: allows 
1. common access via xml-enabled software
2. ascii access to data
3. access from reporting software
4. access from www, wap
5. whatever else

apps: 
1. one filter multiple apps. (e.g. there would be only one MS Word filter for the
whole linux infrastructure, as asked for in some mailing lists)
2. every app could grow and implement newer and more capable conduits in cl2
3. old apps can still access their old fileformat without conduits.

data storage (ds): xml-enabled data storage (as kword files, XML-enabled DBMS)
wouldn't need any cl1 conduit

conduit level 1 (cl1): 

conduit level 2 (cl2):

information broker (ib): is a deamon that gets requests via dcop from applications.
it knows all about the conduits in cl1 and cl2 and the dts 

major concerns:
 * bloatware: only the ib would be needed straigt away to implement the api to the
software. the ib could very well be a kde-pim server in the first place. 
 * takes long to implement: the know how from the conduits is already in the
software. it is merely a task of making to conduits with an xml-layer out of one.
 * how to upgrade: old and new can easily coexist. just the extra value wouldn't be
there for data without conduits in cl1 and cl2
 * should be fast: since there can be (and through filters are already) specialized
conduits, it is easy to make it fast if needed.
 * should be flexible: the two conduit levels are used if indexing, syncing or access
to more than one data storage is needed without a specialiced conduit at hand.

well it is 3:39 am and i got finally tired.

i spent the whole day to upgrade to kde-2.2alpha2 caused by this little
application/octet trouble. so the file with the email adresses is merely complete
yet.

good night (till morning america is working :-)

olaf


-- 
Dipl.-Ing. (FH) Olaf Marc Zanger
Lorrainestrasse 23
3013 Bern / Switzerland
Mob: +41-76-572 9782
["ib-system-layout-0.0.3.pdf" (application/pdf)]

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