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

List:       kde-pim
Subject:    Proposal for the hardware-end of things
From:       "Adriaan de Groot" <adridg () sci ! kun ! nl>
Date:       2001-06-15 23:00:36
[Download RAW message or body]

Attached find yet some more diagrams and a docbook file describing the first 
part of a device-sync architecture that could combine sync tools for a 
variety of hardware devices. In particular, Cornelius, could you have a look 
at this?

[You'll need a running KDE 2.2 system with meinproc installed to compile the 
docbook to HTML, though]

-- 
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/
["multi-device.png" (image/png)]
["kpilot-and-kandy.png" (image/png)]
["Architecture.docbook" (text/xml)]

<?xml version="1.0" ?>
<!DOCTYPE book PUBLIC "-//KDE//DTD DocBook XML V4.1-Based Variant V1.0//EN" "dtd/kdex.dtd" [
  <!ENTITY % English "INCLUDE" > <!-- Change language ONLY here -->
  <!ENTITY % addindex "IGNORE">
]>

<book lang="&language;">

<bookinfo>
<title>KitchenSync Manual</title>

<authorgroup>
<author>
	<firstname>Adriaan</firstname>
	<othername>de</othername>
	<surname>Groot</surname>
	<affiliation>
	<address><email>adridg@cs.kun.nl</email></address>
	</affiliation>
</author>
</authorgroup>

<copyright>
	<year>2001</year>
	<holder>Adriaan de Groot</holder>
</copyright>

<date>2001-06-15</date>
<releaseinfo>0.1</releaseinfo>

<abstract>
<para>
This document describes the setup of KitchenSync, KDE's framework
for syncing data between portable devices (Palm style devices, or
mobile phones, or other mobile computing devices). 
</para>
</abstract>

<keywordset>
	<keyword>KDE</keyword>
	<keyword>KPilot</keyword>
	<keyword>KitchenSync</keyword>
</keywordset>

</bookinfo>

<chapter id="sync">
<title>Device Syncing Architecture</title>

<sect1>
<title>Terminology</title>

<variablelist>
<varlistentry>
<term>The machine</term>
<listitem><para>
refers to the user's desktop computing platform (which might
be a loptop as well -- we mean some device running KDE).
</para>
</listitem></varlistentry>

<varlistentry>
<term>To Sync data</term>
<listitem><para>
means to bring two sets of data in physically or logically
distinct locations into a consistent state. Usually consistency means
that the meaning of the data in both locations is the same.
</para>
</listitem></varlistentry>

<varlistentry>
<term>A device</term>
<listitem><para>
is an external piece of hardware that contains data that needs
to be Synced or backed up on the machine.
</para>
</listitem></varlistentry>

<varlistentry>
<term>A daemon</term>
<listitem><para>
is a piece of software that handles the communication with
a device through some communication port.
</para>
</listitem></varlistentry>

<varlistentry>
<term>A conduit</term>
<listitem><para>
is a piece of software that communicates with a daemon and
that Syncs a specific part of the data in the device with information 
elsewhere. Typically a conduit is part of a daemon.
</para>
</listitem></varlistentry>
</variablelist>

</sect1>

<sect1 id="purpose">
<title>Purpose</title>


<para>
The purpose of KitchenSync is to provide the user with a way of choosing 
which device should be Synced -- since devices may share a communication 
connection with the machine -- and displaying information about the Sync.
To make this possible, KitchenSync has an extensive DCOP interface that
makes it possible for daemons to:
<itemizedlist>
<listitem><para>
Request a specific communication port (this should be denied if
another daemon is busy with that port).
</para></listitem>
<listitem><para>
Indicate what kinds of Sync possibilities (sync, backup, restore, etc.)
the daemon has.
</para></listitem>
<listitem><para>
Start a Sync and display the progress of the Sync.
</para></listitem>
<listitem><para>
Log information about a Sync.
</para></listitem>
</itemizedlist>
</para>

</sect1>

<sect1 id="context">
<title>Context</title>

<para>
The following diagram shows 
which programs (pieces of paper),
devices (grey images),
data files (disk drums)
and communication lines (red arrows).
Communication lines are annotated by the protocol 
that is spoken along them.
Blue numbers in the diagram refer to the list following.
</para>

<imageobject><imagedata fileref="multi-device.png" format="PNG"/></imageobject>

<orderedlist>
<listitem>
<para>
A daemon talks to the device corresponding to it through some
kind of physical communication protocol.
</para>
</listitem>

<listitem>
<para>
The daemon keeps KitchenSync informed of what is going on during the 
Sync by DCOP calls.
</para>
</listitem>

<listitem>
<para>
A daemon can contain several conduits, with which it
communicates through some kind of intra-daemon protocol.
This might be DCOP, might be the old-fashioned KPilotLink
protocol, or it might be shared libraries called from the
daemon code.
</para>
<para>
Each conduit is responsible for some part of the data in the device.
All the conduits together should be able to backup and restore
all the data in the device.
</para>
</listitem>

<listitem>
<para>
A conduit might store data into a file that is a straightforward
binary copy of the device data.
</para>
</listitem>

<listitem>
<para>
A conduit could communicate with a KDE application through DCOP.
Some conduits might commuicate with Keeper, the future
KDE-PIM server.
</para>
</listitem>

<listitem>
<para>
Still other conduits might communicate with external servers,
processes, pipes, whatever.
A mail-sending conduit comes to mind here.
</para>
</listitem>
</orderedlist>

<para>
Note that one conduit might use more than
one data storage method.
For example, a conduit for the address book
in the daemon for a Palm pilot device
might store addresses through DCOP in KAddressBook,
but some Pilot-specific data -- such as category information --
would have to be stored on local disk.
</para>


</sect1>



<sect1>
<title>Current Software</title>

<para>
The following figure shows which functionalities are currently
implemented in the Sync applications (well, we'd call them daemons)
KPilotDaemon and Kandy, the phone Sync application.
</para>

<imageobject><imagedata fileref="kpilot-and-kandy.png" format="PNG"/></imageobject>

<itemizedlist>
<listitem>
<para>
	The cyan line indicates what Kandy does: it
	talks to the phone and copies the Phone list.
	It may Sync with the KDE phonelist, but I'm not sure.
</para>
</listitem>
<listitem>
<para>
	The KPilot daemon and the conduits are separate
	processes, indicated by blue lines 1 and 2 respectively.
	Conduits -- like the address book conduit -- communicate
	with KDE applications through DCOP.
	The daemon itself stores a binary copy of the Pilot's 
	data on disk.
</para>
</listitem>
</itemizedlist>

<para>
All of this just gets the information out of the device and headed
elsewhere. 
It is fully compatible with the KDE-PIM server architecture -- whatever
that may be -- since the conduits can just send information to the
server and have it stored there.
</para>


</sect1>

</chapter>

<chapter id="needs">
<title>What we need</title>

<para>
The previous chapter described a possible architecture for dealing with
the Sync requirements of various devices.
It also described what current software solutions in kdepim do.
</para>

<para>
This chapter adds details about what we would need to decide on 
to get this architecture to work.
</para>

<sect1 id="desktop">
<title>Desktop Files</title>

<para>
KitchenSync needs to be able to identify which applications
are daemons so that it can offer the user the choice of which
daemon to run. 
I'd like to suggest a ServiceType of "SyncDaemon".
</para>

<para>
If daemons share resources -- such as a particular hardware
communications port -- then we need to restrict access
to that resource.
A simple approach would say the resource <quote>Syncing</quote>
is restricted, and only one daemon can run at a time.
Something more sophisticated would add an X-Daemon-Port entry
to the desktop file indicating what kind of port is used (Serial, USB)
and KitchenSync can run one daemon per port type.
</para>

<para>
Let's suppose conduits are separate UNIX processes or
shared libraries. Then we'll need a .desktop file to
identify them as well.
Can you subclass ServiceTypes?
Then Conduit/devicename seems reasonable.
Otherwise a ServiceType of Conduit seems sufficient,
and X-Conduit-Device could be added.
</para>

</sect1>

<sect1 id="ksyncstartup">
<title>KitchenSync startup</title>

<orderedlist>
<listitem><para>
KitchenSync starts and adds an icon to the system tray
with some kind of generic Sync icon. The KPilot Sync
icon doesn't seem suitable since it's the Gr&uuml;ne Punkt
of German recycling, and this may be confusing.
Something that resembles the Palm HotSync icon may be better.
</para></listitem>
<listitem><para>
KitchenSync queries for applications with ServiceType SyncDaemon.
Their names are added to a popup menu.
</para></listitem>
<listitem><para>
When the user selects a daemon, it is run.
</para></listitem>
<listitem><para>
When a daemon is run, it registers with KitchenSync.
This might be refused if there is already a daemon running
or somesuch -- obviously you can run a daemon from the command line
as well.
</para></listitem>
<listitem><para>
The daemon tells KitchenSync what kind of Syncs it can do. These
are added to the popup menu.
A daemon might respond to data coming from the device to
start a Sync, or it may start a Sync programmatically.
This might be configured  as well.
</para></listitem>
<listitem>
<para>
KitchenSync might show a progress bar window,
or a window with a Sync log of messages.
</para>
</listitem>
<listitem><para>
If the user selects a different daemon, the current daemon is told
to quit and the new one is started from step 3.
</para></listitem>

</orderedlist>

</sect1>

</chapter>

</book>


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