[Zope] Pilot? (Was: ANNOUNCE: Zope/XML Roadmap)

[Ty Sarna]

In article <4.2.0.58.19990722122859.00d6c2e0@lisp.atmm.nl>,
Martijn Pieters  <mj@antraciet.nl> wrote:
> Pilot? As in Palm Pilot? (MJ Flaps his ears and waves his new IIIx). Can 
> you tell us more?

Sure...  here's a little prepared explanation. It's a bit out of date
now, but the basics are there.

Note that progress is pretty much stalled while I finsh up some paying
gigs and relocate.  Also, ZClasses, the Catalog, and other developments
have some interesting implications, and I need to think about those
before I continue.  I expect to get back to it in the early fall. 

---

Since I first saw Principia, I've been think about what sorts of
interesting applications it could be used for. Some things are obvious,
like trouble ticket systems and community portals. But I've been
wondering what kinds of programs could be written as web
applications that traditionally never have been. I've got 3 interesting
ideas so far.

One I came up with is something I needed anyway, a good "desktop" for
the Palm Computing Platform.  pilot-link is very, very basic.  KPilot is
not very extensible.  But a Zope-based desktop has some interesting
benefits.  First, it's easy to extend.  Second, it's a GUI appliction
(albeit not with the slickest possible interface, due to the limitations
of html), without introducing the problems of portability or all the
labor required for a traditional GUI.  Third, it means not only can you
take your data on the road in the pilot, but you can also access it on
the road via a web browser.  Fourth, you can sync over the web, if you
have appropriate client software and a cradle on the local end. 

Since I'm making good progress on it now, I though I'd share a sneak
peak.  Here's what I have so far.  The architecture consists of two
parts: a sync client and the desktop.  The sync client needs Python
1.5.2, the pilot protocol libraries from pilot-link, and part of Rob
Tillotsen's Pyrite interface to those libraries (I use his basic DLP
stuff and record packing/unpacking stuff, but I did my own conduit
framework that's a little different). Individual conduits are
implemented in separate modules. The other part is written entirely as a
Zope product that provides several different kinds of objects. This part
is currently called "Dezkset", becuase I can't think of anything better.
Suggestions for a better name would be appreciated :-) (please be aware
that I can't use "Palm" in the name due to Palm Computing's enforcement of
that trademark).

The sync client software is configured with the URL of a locator
service. When the user initiates a sync, it first retrieves the user
name and ID from the device and sends it to the locator service.
The locator service returns a URL for the root of that user's dezkset.

The nice thing is that the locator service can be anyting you want.  In
my case while I'm still writing and testing the software, I just have a
simple DTML Method that returns a text/plain document with the hardcoded
URL of my dezkset.  However, you can do anything you want here.  Use the
ID or name to index into a SQL table with Z SQL Methods.  Use the Zope
LDAP support that is being talked about.  Whatever -- you can do
anything you want.  The locator service doesn't even have to be on the
same machine as the dezksets, so you can just have a plain CGI service
somewhere else, if you want. 

Ideally, each person at an organization runs the client on their
desktop.  Because of the locator service, anyone can sync their device
using anyone's cradle, and it will sync to the appropriate dezkset.
There could even be "public" cradles available. You can also sync over
the Internet from anywhere in the world.

Once the dezkset is located, the client runs sync conduits as necessary,
speaking HTTP to the dezkset to obtain the necessary information. The
information is returned in XML format.

The dezkset consists of the following objects:

Palm File - subclass of File that knows a little bit about the internals
of .PDB/.PRC files and can display various header information. For
resource files, it'll show you a little table of all the resources.

Dezkset - foldoid representing a user's palm desktop. Acts like a
regular folder, but retains order information (to decide in which order
to run conduits) and allows conduitish objects to be enabled/disabled.

TimeSync - conduit object. Used to sync the device's clock to the time
on the sync client system. The user can pick the schedule on which to
sync the clock (Every Sync/Daily/Weekly/Monthly).

Backup - Foldoid conduit.  User selects schedule (every n
syncs/days/weeks) and options (full or incremental backup, and wether to
backup only stuff that asks for it, or ignore the backup bit and back up
everything). Backed up files are stored as Palm Files in the folder.
You can have more than one -- I have an Incremental backup every sync,
and a Full/Ignore Backup Bit backup every week.

Installer - Foldoid conduit. Put any Palm Files in this folder, and
on sync they will be installed to the device and deleted from the folder.

Memo Pad - in progress. I have generic mixin support (both for the sync
client and Dezkset) for syncronizing categories between the palm and
dezkset, which works. I'm still writing the management interface for
memos. The goal is to have Memo Pad be a foldoid that takes any Zope
object, plus special Palm Memo and DTML Memo objects. Palm Memos are
regular memos that will be synced bidirectionally. DTML Memos will be
special: they'll always be considered modified, and will always override
the matching memo on the Palm. Unlike regular memos that contain plain
text, DTML Memos contain (surprise!) DTML which is rendered to produce
the final text that will be put on the palm device. So, you can write an
external method that fetches the latest weather forcast, and have a DTML
Memo that calls it. Then every time you sync, you get the latest
weather. Or, use the contributed slashdot-fetcher product to get the
latest headlines. Whatever, the choices are limitless. (This by the way
is why the MemoPad can contain any Zope object -- convenience so you can
group any external methods or other objects used for DTML Memos together
in one place). I'm thinking now that I may split it, sort of like
Confera, so that the generic zope objects and Memo contents are separate.

ToDo and AddressBook - once the generic sync support for Memos is done,
these will be fairly straightforward.  The hardest part will be the zope
management interface (which is not terribly hard).  I'm going to do
vCard support of some kind for AddressBook.  It'd also be nice to have
"replicator" addressbook entries that get theirinformation from another
source periodically, so selected entries in you adressbook can be kept
in sync with a company employee database, for example.

DateBook - Similar to the above, but the sync logic has a few extra
complications (conflicting appointments). Some clever person already
wrote a calendar display tag that will make the management interface
easy :-) I'd like to support vCalendar and/or iCalendar stuff.