On 10-May-99 Dave King wrote:
> We are trying to set up a situation where multiple palm devices dial in and
> transfer data to a server. This works well with the modem hotsync as long
> as the device dialing in is know to the hotsync manager. It there anyway to
> turn off the step in hotsync where it tries to identify the user? Is there
> a product on the market the replaces the hotsync manager to allow multiple
> concurrent anonymous hot-syncs / data transfers?
>
> I know I can accomplish this via some socket code, but we'd prefer an off
> the shelf solution is there is one.
You are welcome to skarf code from GNUGotMail. It's a GPL'd mailer I'm
writing that is currently in Alpha, very similar to TG Postman. Anyhow it
has code to pack dirty/deleted records into a PDB file that it sends as a
base64-encoded mail attachment. I then use a couple of Perl scripts to merge
these subsetted PDB files into a repository.
The THEORY is that you can send your one-way file changes to an email
account, and then use whatever mail processing tools (I use procmail) to take
it from there. It should work on just about any shell account because I
wrote the Perl scripts to not use any dependencies. Here is my .procmailrc:
UMASK=007
:0 c
* ^From:.*chrisf@america\.com
* ^Subject:.*GNUGotMail
* ^X-GNUGotMail-Secret:.*mysecretpassword
| (cd /home/goodies/sync; pilot-base64.pl >> pilot-merge.log)
I have more information on my page:
http://www.america.com/~chrisf/web/pilot/pilot.html
The program still needs to have an exclusion list, and perhaps a way to
decode some attachment types. Two things come to mind; Once you sync your
data you could use a Perl script to create/update web pages. Or you could
sift through the replaced/added Datebook records and create vCalendar
attachments for your private mailing list.. and then if you had a Pilot
mailer capable of receiving these you could have a shared calendar.
The approach I took was to create real PDB files.. but these PDB files will
usually only have the dirty/deleted records from the device. I thought it
would be easier to use the PDB format to send the file changes rather than
come up with some proprietary structure. The only problem I ran into is that
files can also be modified such that the records are in different order. And
in the case of non-conduit based files, they will not have delete stubs for
deleted records.
To overcome those issues I put a proprietary sortinfo structure into the PDB
file (only the one coming from the device.. as the one in the repository is
left blank). This sortinfo structure is all of the 3-byte unique IDs
back-to-back, so I can tell how to reorder the new file and I can also tell
which records are missing. This allows me to do an incremental sync on
non-conduit based files as well.
BTW, I suppose I will announce this puppy sometime when it reaches 1.0. I've
been the only one testing it out, so I'm a bit anxious unless some other
people have tested it. So I'd appreciate any bug reports/fixes :)
/* Chris Faherty <[EMAIL PROTECTED]>, finger for PGP */
