>>>>> "Thomas" == Thomas E Deweese <Thomas> writes:
Thomas> If you want both stored in one palm record, uhh find another
Thomas> sync tool, I consider this approach a hack job. I'd be
Thomas> delighted if plam updated the address book app to support
Thomas> multipled addresses (or in BBDB terminology 'locations) per
Thomas> 'person' but since it doesn't I consider this the proper way
Thomas> to deal with the issue.
>>>>> "Jack" == Jack Twilley <[EMAIL PROTECTED]> writes:
Jack> That's a remarkably inflexible position for an application
Jack> author to take.
Thomas> I really don't mean this to be inflexible or stubborn but
Thomas> SyncBBDB is not what I get paid to do, and I _really_ do
Thomas> consider it a major hack job. I really don't want to have to
Thomas> write fuzzy parsing code just so I can try (often
Thomas> unsucessfully) not to completely mangle your BBDB record when
Thomas> you try and add some information to your note on the
Thomas> Palm. It's just a loosing proposition, and beside the
Thomas> technical issues of dealing with user edited junk, I _really_
Thomas> strongly prefer the current setup.
I understand that SyncBBDB isn't your day job. I don't know of
anyone, Rowan included, who gets paid to hack on bbdb. The parsing
code isn't that bad -- jwz wrote it in his bbdb-pilot.el.
Jack> I consider the approach of making multiple records for a single
Jack> individual to be worse than a hack job as it totally skews the
Jack> meaning of the records and makes incorrect assumptions. A
Jack> one-to-one correlation between BBDB records and Palm address
Jack> book entries makes a lot more sense to me, as it is not uncommon
Jack> for me to have more than one set of phone and address for
Jack> coworkers (and family and close friends).
Thomas> I also regularly have multiple phone and address entries for
Thomas> coworkers and friends and family. This is why I did this
Thomas> (trust me maintaining a many to one relationship is _MUCH_
Thomas> more work than just slamming everything into the note field).
Instead of asking me to trust you, try to explain why it's easier that
way? I can see only one way it may be easier, and that's in modifying
information on the Palm and having it update properly in the bbdb. I
see several ways it is not easier, and I've described some of them.
Jack> But just because I have Home contact information for people does
Jack> not mean they are in the Personal category, it just means I have
Jack> Home contact information for them.
Thomas> Sure, it doesn't mean that they _must_ be in the personal
Thomas> category but some of my entries _are_ because I have personal
Thomas> relationships as well as work relationships. Not possible if
Thomas> everything is crammed into one record.
So you're telling me you like having a friend who is also a coworker
in both Business and Personal? That almost makes sense. What about
your wife/girlfriend/whatever? If you have several different kinds of
contact information for her (say, home, work, and her parents) then
what? You'll have *three* Palm address book entries? That's more
reasonable than one Palm address book entry? Here's another example:
I have my personal care physician in my palm, with two different
phone-address combinations, one for each office. Does that justify
two records? I don't think so, personally. I'm asking these
questions not to argue but to understand your design philosophy. So
far, the only bit I've seen is "Multiple Palm address book entries are
the best way to transfer bbdb records with multiple addresses, and
anything else is a hack job.", and I'm hoping there's more to it.
And it's easy to have personal relationships as well as work
relationships with a single Palm address book entry. You just don't
put them into different *categories*, that's all.
Jack> I don't need to tell you how ugly it would be to have multiple
Jack> records in the same category for the same person, do I?
Thomas> Why is this so ugly? I set the overview field to be the phone
Thomas> who's location matches the address's location for that record.
Thomas> So I see:
Thomas> Thomas DeWeese (XXX) XXX-XXXX H
Thomas> Thomas DeWeese (YYY) YYY-YYYY W
Thomas> If I really want to know where I live I click the 'H' one,
Thomas> if I really want to know where I work I click the 'W' one.
Thomas> It is really quite nice.
I guess your "nice" is my "ugly". To me, having more than one Palm
address book entry for one person is ugly. It's ugly because it
forces me to categorize people based on how much information I have on
them instead of how they interact in my life. The paper-based
daytimer I used to use before I converted everything to my Palm
supported multiple addresses. The bbdb-pilot.el tool I used before I
started using SyncBBDB supported multiple addresses.
Thomas> Also (from your comments below) you might not have noticed
Thomas> that as much as possible SyncBBDB will put all
Thomas> phones/email/fax in all records. So in most cases you can get
Thomas> to both home and work phones in both Palm records, thus in
Thomas> most uses it doesn't even matter which one you click on - if
Thomas> the default didn't do this because it ran out of fields you
Thomas> can edit the pilot-id thingy to change the mapping to include
Thomas> the five you want (or seven if you map to the custom fields)
Thomas> (I still really need to get around to writing e-lisp for
Thomas> manipulating the pilot-id thing)..
I saw the phone numbers. Now, what happens if "Mobile" is the first
number displayed -- they'd both be the same, right? I've run into an
unrelated difficulty, which is how to categorize a work mobile phone
separately from a personal mobile phone. Suggestions on *that* would
be dearly appreciated.
Jack> With all due respect, it would probably help more than one user
Jack> of your software for you to consider adding functionality to
Jack> support a one-to-one record-to-entry relationship, with the
Jack> additional address information stored in the Notes field, and
Jack> completely populating the available contact information fields.
Thomas> Since you don't seem to care that all the semantics of the
Thomas> information is lost when you cram it into the note field on
Thomas> the Palm, why don't you just cram the 'extra' information into
Thomas> the note field on BBDB?
Thomas> Probably Answer: because that would be a hack job :)
The Palm doesn't support multiple address entries in a single address
book entry. But bbdb does support multiple address entries in a
single record. So I try to take advantage of the capabilities of each
tool. I care that the bbdb record is properly structured and I use
tools to access that information by way of its structure. The
manner in which you chose to translate bbdb records into Palm address
book entries doesn't meet my needs. Excepting that one flaw, the rest
of SyncBBDB is *exactly* what I need.
Jack> If this is something that truly goes against your address book
Jack> philosophy, then I'll probably have to hack up your wonderful
Jack> code to add this functionality and then post it here and
Jack> elsewhere for other people who might want to use it.
Thomas> Well first I'll have to put a real GLP license on it
Thomas> (something I've been meaning to do anyway). If you can make
Thomas> it a clean patch I might consider including it, but you
Thomas> probably wouldn't want to do that anyway since all my
Thomas> documentation would talk it down :)
According to the syncbbdb2 SourceForge site, the code is GPLed. It
shouldn't be difficult to make a clean patch like this:
if ($keep_jmt_sane) {
# my code
} else {
# your code
}
Thomas> Sorry I can't/won't be of more help here. Good luck.
Stay tuned for patches. Would you like them posted on the syncbbdb2
SourceForge site?
Jack> Jack. (you should also respect X-Attribution settings)
Thomas> Sorry, my SuperCite always gives stupid suggestions for cites
Thomas> so I always just override with Initials (don't know why you
Thomas> ended up with just J and not JT thought). It's also funny
Thomas> that nobody objects to '>' but (even if they have
Thomas> X-Attribution set) but if I site with initials and they have
Thomas> X-Attribution set tell me I screwed up :)
People don't object to > probably because they figure you're not using
Supercite. It's pretty easy to set up the suggestions. Here's my
config:
(setq
sc-attrib-selection-list '(("sc-from-address"
((".*" . (bbdb/sc-consult-attr
(sc-mail-field "sc-from-address"))))))
sc-mail-glom-frame '((begin
(setq sc-mail-headers-start (point)))
("^x-attribution:[ \t]+.*$"
(sc-mail-fetch-field t) nil t)
("^\\S +:.*$"
(sc-mail-fetch-field) nil t)
("^$"
(progn (bbdb/sc-default) (list 'abort '(step . 0))))
("^[ \t]+"
(sc-mail-append-field))
(sc-mail-warn-if-non-rfc822-p
(sc-mail-error-in-mail-field))
(end
(setq sc-mail-headers-end (point))))
sc-preferred-attribution-list '("sc-lastchoice"
"x-attribution"
"sc-consult"
"initials"
"firstname"
"lastname")
sc-citation-leader "")
Hope that helped. Oh, and yes, I'm trying to figure out what in the
sc<->bbdb interaction causes some addresses to be displayed improperly
in attributions.
Jack.
--
Jack Twilley
jmt at twilley dot org
http colon slash slash www dot twilley dot org slash tilde jmt slash
msg02814/pgp00000.pgp
Description: PGP signature
