Petaris> Hi vanRijn
<Petaris> Hows the kpilot stuff coming?
<vanRijn> petaris: blef
<vanRijn> Petaris: I still don't know how to pull off the per-db full/hot-sync decision
<Petaris> that well huh
<Petaris> well, I am not a programmer but
<Petaris> during the sync could you do an md5 sum on the pdb files and keep a log of them in kpilot somewhere
<vanRijn> also, I realized last night that kpilot has absolutely zero support for maintaining categories correctly. I looked at judd's jpilot code for taking care of category syncing and about fell out of my chair at how much is involved in doing it correctly
<Petaris> yeah
<judd> Hehe, its actually impossible to do 100% correctly. Thats why I resisted it for so long.
<Petaris> I have not used kpilot really, I always uesed jpilot if I needed a desktop app
<vanRijn> judd: hey man.
<judd> hey vanRijn
<vanRijn> judd: dude, seriously, nice work in jpilot. I have total respect for you after last night. =:/
<vanRijn> I mean, I did before that, but it was ^2'd last night
<vanRijn> judd: how long has that code been in there then?
<Petaris> Hi judd
<judd> heh, the code is messy, but works. The i18n confuses me.
<judd> Hi Petaris.
<judd> Thats why I get mad when people tell me its just a front-end to pilot-link.
<judd> Probably 3 years or more I'd guess.
<vanRijn> judd: and I'm not sure how much of it I can pull off correctly from kpilot being that there's normally no UI up when the sync is happening for the "do you want me to move all of these entries from category X to category Y or just delete them?" types of interactions
<vanRijn> I haven't looked at gpilotd's code for category handling, but I cannot imagine that they do it as well
<vanRijn> and I totally do not get the 0-127 versus 128-256 ids thing
<vanRijn> and kpilot doesn't even reference renamed[] either
<vanRijn> *sigh*
<vanRijn> totally unmotivating
<Petaris> gpilotd works but its not as nice as jpilot in my opinion
<Petaris> but its the only solution for evolution syncing
<judd> In my BUGS file I have something cryptic written up for it. It made sense to me when I wrote it :-)
<judd> If an ID is created on the Palm it gets 0-127, on the desktop gets 128-256. Unless I have that backwards.
* bhargavi has quit (Ping timeout: 255 seconds)
<vanRijn> judd: can you recommend a really good book that would go into the details of some of this esoteric stuff? like renamed[], 0-127,128-256, database structures, conduit programming, etc.?
<vanRijn> judd: yeah, I got that, but I don't get what purpose they have--or why it's necessary. what if I just use 0-15? does the palm blow up?
<vanRijn> and I'm assuming you're referring to the category ids, right?
<judd> The *only* one that I know of is Palm Programming, the developers guide, O'reilley.
<vanRijn> where are they even used?
* vanRijn looks
<Petaris> vanRijn, it only blows up if its a Sony Palm device, otherwise it just bricks them ;P
<vanRijn> petaris: heh
* zinx has quit (Ping timeout: 134 seconds)
<judd> Say you created cat #6 on the palm, and created #6 on the desktop. At sync time there would be no way to know if they were both new, or renamed. Hmm, maybe the lack of a rename flag.
<vanRijn> yeah, exactly
<vanRijn> but either way, how do you handle that?
<vanRijn> and without user interaction?
<vanRijn> you have X amount of records that have category id of 6... the hard part is the name... which one to take as master, right?
<vanRijn> I don't see how the ID helps with that at all
<judd> Its in this book. I don't think you can make the right choice without the user always.
<vanRijn> and... I guess I'm assuming.... the record's category id... does that map to the ID or the name[] index?
<vanRijn> the _PilotRecord's int catID...
<judd> I'm not finding it in this book. I think it may be in a Palm created pdf file I found a long time ago.
<vanRijn> if that is assigned to name[1] == "Wibble", and ID[1] == 25, does _PilotRecord->catID == 1 or == 25?
<judd> I believe the record cat ID maps to the index, not the ID.
<vanRijn> okay, phew
<vanRijn> that's how I've always been thinking about it
<judd> Yes, because it is only 4 bits long.
<vanRijn> that's how kpilot treats it
<vanRijn> so, then, the unsigned char ID[16] makes absolutely zero sense to me
* bhargavi (~bhargavi@59.92.191.212) has joined #pilot-link
<judd> Well, they are like record IDs. Say you rename cat ID 30. If there is a cat ID 30 on the desktop and the name differs then it assumes a rename.
<judd> If there is no ID 30 on the desktop it assumes that it is new.
<vanRijn> yeah, but couldn't you get the exact same functionality by just looking at the names[] array?
<vanRijn> I mean, if I didn't have name[5] before, and now I do, or if it's different than what I had before... I have the same problem and same solution, right?
<judd> How would you know name[5] wasn't added on the palm and the desktop?
<vanRijn> but what does it matter?
<judd> If the name is the same it doesn't and you would not sync anything in that case.
<judd> If they differ then you have to gice one of them a new index and change all of the records to match the new index.
<vanRijn> unless you're going to keep both and move all records from catID 5 to catID 6 (and if so, which one do you move)...
<vanRijn> ah
<vanRijn> blef
<vanRijn> what a pain