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.