[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coldsync-hackers] address and datebook conduits.




Wow, I got the Chief's attention.  Cool!

Andrew Arensburger writes:
> 	Shameless self-promotion: see
> http://www.ooblick.com/text/perl/

Thanks a lot for the pointer!  I need all the help I can get.

> 	For instance, each AddressDB record contains a flags field
> that indicates whether the record contains a first name, a last name,
> a company name, etc. In Emacs, it would make more sense to just have
> 
> 	First Name: 
> 	Last Name: 
> 	Company:
> 	...
> 
> and allow the user to fill in the blanks (or not) any way he chooses.
>
> 	Obviously, one way to handle this would be to have Emacs hooks
> that parse the PDB file when it's read, convert it to text, then
> convert the text buffer back to a PDB when it's saved. However, this
> seems clumsy.

Agreed.  coldsync (and p5-Palm) provides the guts of reading and
writing PDBs, syncing between them and the Palm, and dumping text
files (via conduits).  Given this, writing an elisp package to parse
PDBs into buffers for editing would seem to be reinventing the wheel,
and would only help Emacs users.

The trick is the text format that the conduits dump and fetch....

> 	A better approach would be to use a standard text format that
> can be edited any text editor, be it Emacs, vi, or Notepad, and have
> Perl scripts (or whatever) to convert to and from PDB format. In
> Emacs, you can have a mode for the various text formats.

To first order, the format of these text files makes little difference
to someone who uses vi or Notepad, because they have to edit the
entire thing by hand and play by the rules themselves.  As long as the
format is reasonable, they don't care about its specific structure.

In Emacs, you can write elisp routines that help edit the underlying
text file.  In particular, you can ensure that the records remain
structured so that they parse properly during conduit fetch, whereas
the user has to stay much more disciplined using vi or Notepad.  (I
would say this is particularly true of the Emacs bbdb package for
addresses, and to a lesser extent of the Emacs diary/calendar.)

To take advantage of this sort of functionality in the short term, I
was inclined to have conduits spit out text formats expected by the
already-written Emacs packages, as least as an option.  This would
immediately allow use by other Emacs users, as opposed to relying on
me for reliable elisp packages.  (Admittedly, the bbdb format is not
particularly attractive to vi or Notepad users; the diary format may
not be so bad.  The BBDB perl package, or the bbdb perl routines in
SyncBBDB might allow for exporting to other formats.)

> 	One useful thing you could do would be to come up with file
> formats that are editable in Emacs, and also contain the information
> that conduits will need.

I've taken a look at the SyncBBDB conduit written by Thomas DeWeese
for the PilotMgr sync manager.  It's in perl, and it seems to me that
a lot of the code and functionality could be converted into a very
powerful coldsync conduit.  The package adds an extra "notes field"
with tag "pilot-id" to bbdb databases to hold pilot-specific
information.  I think it also uses a file of checksums for each bbdb
record so that the conduit can tell which records in the bbdb file
have been modified.

My guess would be that the Emacs diary file format could be quickly
adapted to support an additional tagged line with pilot information.
Taking some examples from the Emacs info files, and following
SyncBBDB's structure:

     02/11/1989
           Bill B. visits Princeton today
	     pilot-id: 33535 Business
           2pm Cognitive Studies Committee meeting
	     pilot-id: 56234 Business
           2:30-5:30 Liz at Lawrenceville
	     pilot-id: 35456 Personal
           4:00pm Dentist appt
           7:30pm Dinner at George's
           8:00-10:00pm concert

Emacs could treat the information as part of the description, while
the conduit could use it to do "the right thing".  I guess it's all a
matter of how much functionality of the two different packages one
wants to support, and do something reasonable with the exceptions.

Finally, adding a small amount of lisp code to bbdb and diary to
prevent users from munging the extra pilot information in a relatively
standard emacs file format would seem easier than writing an entire
new package for a new format.  It would more likely be accepted in the
Emacs world, too.

> Of course, I've just made this up, since I'm not sure which standard
> Emacs formats exist for these sorts of things.

I'll throw out some packages that I use for various things, just to
see what other people have to say.  This would be my first cut at
trying to match things up with the Palm.

Addresses: bbdb mode
DateBook: diary mode
Memos + Todo: records mode

> 	This sounds like a cool and useful project (meaning: this is
> the sort of thing I'd personally like to be able to do).

Same here.  Problem is time (I'm also trying to write my thesis) and
experience (I don't know perl or elisp).  Banding together with others
having similar interests would be great.


Cheers,
Nick
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.