[OPIE 0000356]: addressbook: Doesn't deal with Sharp .xml file well

The following bug requires your FEEDBACK.
=======================================================================
http://131.152.105.154/mantis/view_bug_page.php?f_id=0000356
=======================================================================
Reporter: docwhat
Handler: eilers
=======================================================================
Project: OPIE
Bug ID: 0000356
Category: PIM/PIM apps
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
=======================================================================
Date Submitted: 10-28-02 17:44 CET
Last Modified: 10-29-02 16:34 CET
=======================================================================
Summary: addressbook: Doesn't deal with Sharp .xml file well
Description:
If you copy the Sharp .xml file for addressbook over, it'll get cranky
because it is possible to have a contact with a Uid="0". In general,
addressbook doesn't deal well with multiple contacts with the same Uid.

It should simply reassign any "Uid" that is 0. If there are two or more
Uids that are the same, then it should pick one at random (to stay that
Uid), and re-assign the other Uids.
=======================================================================

-----------------------------------------------------------------------
 eilers - 10-29-02 09:15 CET
-----------------------------------------------------------------------
Could you please tell me, If you ever have synchronized ? And if yes: Which
tool (Qtopia-Desktop, Intellisync) did you use.. ??
Thanks !

-----------------------------------------------------------------------
 docwhat - 10-29-02 15:43 CET
-----------------------------------------------------------------------
I cannot remember if I have ever syncronized with this .xml file.
I think that I may not have. Though some of the addresses came from a
"convert your palm addressbook" script I found someplace.

I do think that this is bad XML, but there is no reason not to handle it
well. Plus, since it *is* XML, if someone edits it by hand, it should try
to be accepting (within reason) of small errors.

Ciao!

-----------------------------------------------------------------------
 eilers - 10-29-02 16:11 CET
-----------------------------------------------------------------------
First of all: Sorry for the inconvenience !

Maybe this palm-script created these UID's .. Could you give me the script
or the address where to find it ?

But general:
You are right: It is not "bad" xml, due to a missing DTD which defines what
is right and wrong..
But not everything is ok, just because we using XML.
The new Database uses the UID for internal addressing (to be exact: it is
needed to differ entries). If it is not unique as expected, it has to fail.

Editing by some scripts is dangerous, because the structure of the XML- may
change in future. We created a complete API to avoid problems and expecting
the XML-File as "machine generated" ( as it is in most cases ). Therefore
it is not as error resistent as you might expect. Especially the UID is the
"Achilles heel" for us..
Even every synchonization mechanism must fail, due to missing comparing
capabilities between Contacts with non unique UID's..

-----------------------------------------------------------------------
 docwhat - 10-29-02 16:34 CET
-----------------------------------------------------------------------
No inconvenience. I want to help.

I don't have the script anymore. I did this when I ditched my Palm way
back when (Uhm...july? Whenever the 5500 first came out. I bought one that
weekend. :).

I understand that it is supposed to be a machine only file, but as long as
the file is out there.....

When the file is loaded, doesn't it know which UIDs have been loaded?
Couldn't it either: a) Throw an error and refuse to allow editing until it
is fixed (or just quit after displaying the error). b) assign a new UID?

It seems that if *ever* a bug happens or a uid becomes corrupted that we
risk important end-user data.

I understand it is expecting perfectly formed data, but it should be able
to know when something isn't right and do its best to protect the data.

I doubt this issue will go away when it is switched to a DB format, since
it'll still be a file. This would be also usefull for detecting errors due
to future changes in the code, so at worst, consider it a debugging tool.
:-)
Received on Tue Oct 29 16:11:40 2002