[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [coldsync-hackers] record attributes madness
On Saturday 11 October 2003 12:05, Andrew Arensburger wrote:
> > The short summary is that any chunk of code which mixes ColdSync::SPC
> > records with Palm::PDB records is in trouble.
>
> Gah! You're right.
> Alessandro, in case I hadn't pointed it out before: this looks
> as if it might introduce user-visible changes, and break existing
> code. In the past, when this has happened, I've incremented the minor
> version number (e.g., 1.1 -> 1.2) even if it was a comparatively small
> change.
Because of the larger installed base and the fact that it's not as closely
tied to ColdSync as ColdSync::SPC (and, in fact, is used independently in
many cases), changing Palm::PDB (even with version number increments) is
probably the Wrong Thing to do. Especially if, as you suggest later,
Palm::PDB/pdb.h better reflect reality.
> I think the best solution might be to find those sets of
> identifiers that refer to the same flags ("Busy" and "deleted",
> "Secret" and "private", etc.), and issue a warning in Palm::PDB::Write
> if they are used. (I'd love to check for those at compile-time, but
> can't think of any way to do so.) Perhaps add a flag so that
> use Palm::PDB("sdk_attrib_id_compat");
> doesn't issue warnings.
Given that the PalmOS 5+ attributes names are newer and probably aren't as
heavily used, it might be worth just dropping them entirely and warning
when they're seen in any records.
> > ColdSync::PDB is an obvious
> > candidate,
>
> Candidate for what? I'm not quite following you.
Candidate for trouble. It uses the Palm::PDB helpers and, indirectly,
Palm::PDB->new_Record(). But it also does things like writing these
Palm::PDB records to the Palm using ColdSync::SPC. That's the simple
scenario. Put these flags into real live database records and repeat the
sync cycle a few times and I'm sure we can come up with all kinds of
disasters.
In other words, attribute handling in ColdSync::PDB is broken and can't be
fixed unless Palm::PDB and ColdSync::SPC are both using the same
conventions.
> When I first started playing with this stuff, I found that the
> identifiers in Palm's SDK didn't seem to correspond to reality, at
> least not the way I saw it.
> What they called "busy" didn't mean busy at all, it meant that
> the user had deleted the record.
Wow. Okay. Well, I said that the person writing DLCommon.h was probably
smoking something.
> The change from "archive" to "archived" is a change from an
> adjective to an imperative verb: at sync time, the record has not yet
> been archived. Rather, this is a command to HotSync to archive the
> record.
That sounds like a great explanation, but it's implemented backwards. A
record fetched via ColdSync::SPC has the "archived" attribute while one
fetched via Palm::PDB has the "archive" attribute.
It looks to me like the archive/expunged flags are always intended to be
treated as imperative by sync logic and as "don't screw with this, it's
going away" by anything else that might stumble across them.
> > My gut instinct at this point is to add the PalmOS 5 naming conventions
> > (Delete, Dirty, Busy, Secret, Archive) to ColdSync::SPC and just stick
> > with those for any future work.
>
> I disagree: I think the identifiers in "include/pdb.h" are the
> most descriptive and intuitive ones; everything else should be based
> on those.
Okay. If you're saying that you've actually tied the naming of pdb.h flags
to the PalmOS behaviour I'm certainly not going to argue. I'd really like
to not see pdb.h/Palm::PDB have to change.
That means changing ColdSync::SPC. From previous discussions on this list,
it sounds like that won't impact many conduits. Unfortunately, the dual
meaning of "deleted" might cause some very subtle bugs in the places that
it is used.
> I feel that readability is more important than adherence to
> the SDK. It's not as if anyone is expected to use Palm's SDK directly
> when writing ColdSync or Palm::PDB code.
No, of course not. I really just brought up the Palm SDK so that we can all
understand the level of confusion I'm having. I wasn't sure if the
underlying problem was driven by changes in different versions of the Palm
SDK or just historical divergence.
It also doesn't help that pilot-link seems to follow the Palm SDK
conventions... I didn't look too closely at how it interprets the flags,
just at the naming. I'd really rather not know at this point.
> But thanks for pointing this out. I hope my comments made sense.
Definitely.
c.
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.