2933 - Palm Pilot/NS Adbook synch probably needs UTF-8 to local folder conversion for off-line DS folder items

Status: RESOLVED INVALID

(MailNews Core :: Internationalization, defect, P2)

Description

[Katsuhiko Momoi]

(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #333020
http://scopus.netscape.com/bugsplat/show_bug.cgi?id=333020
Imported into Bugzilla on 02/04/99 18:03)

** Observed with 10/20/98 Win32 4.5 RTM version **

After conversing with Tony Robinson and Rich Pizzaro, I thought
it might be a good idea to raise this question.

We have localized the dialogs in the Palm Pilot-NS AdBook synch into
Japanese. Our findings indicate that local address book folder entries
are exchanged correctly. Our default charset IDs for local AdBook folders
would generally match that of localized Palm Pilot and this is good.
Good news is that this first case would at this point constitute a huge
percentage of cases.

It seems, however, that off-line Directory Server folder entries will
*probably* not work for 8-bit data without some conversion since our DS
data will be in UTF-8. A good strategy here would be to assume that
the target charset is the same as the local AdBook CSID and do UTF-8
to LocalCSID and the reverse as data are exchanged between Communicator
and Palm Pilot.
(Scott, please confirm that we are using the DS folder data as is
 when synching with  Palm Pilot.)

Fortunatley I think the latter case should account for a small
percentage of users only at this time.

Per conversation with Rich and Tony, I'm filing this as a request
for enhancement in the next release. This will be a good enhancement
for enterprise market where DS use is/will be most prevalent.

Comment 1

[rhp (gone)]

I think this will be part of the 5.0 effort. Scott, does this look
reasonable for us to do a conversion for offlined databases?

- rhp

Comment 2

[Scott MacGregor]

Rich, when your APIs ask for data from the offline database, I convert the UTF-8
data into the character set of your context (in this case the context you use to
create an AB_Pane). One fast solution is to make sure the win_csid for the
context is say the system default (or whatever csid we need to be in synch with
the palm pilot). Then any time you ask for data, I will automatically handle the
conversion....

The longer term solution is to look into expanding your calls into abcom.h to
require the caller to pass in a csid.

Comment 3

[rhp (gone)]

Oh, so maybe my context is just not setup correctly. I will look
at the context that I use to create the AB_Pane. I think I just
create a "dummy" context and use that, so the question is how I
set the csid for my dummy context?

- rhp

Comment 4

[Scott MacGregor]

context->win_csid is the field you want to make sure is set in the context you
pass to the AB_Pane on create.

I'm not sure what csid we want to assume your palm pilot is in though....hmmm.
Are there specs about this issue and the pilot?

Comment 5

[rhp (gone)]

I think we should assume is that the default character set for
the desktop is the one we will use for the Pilot. I don't know
of anything we can check in the pilot to verify what they are
using.

- rhp

Comment 6

[rhp (gone)]

Scott and I were looking at this problem and we have a question:

  - should we assume that the Pilot's character set is the system default
    or the Communicator Global Default?

- rhp

Comment 7

[Katsuhiko Momoi]

I think the former (system default) would be better.
The user won't be using this synch feature unless he/she
can view the entries in the off-line UTF-8 DS folder in Japanese.
People who want to view Japanese entries are generally using
Japanese Windows. Likewise for Chinese, Korean, etc.

I know this means that we will be slighting those people who might be
using PalmSynch in Japanese but Communicator under English Windows,
but that would be acceptable.

In the best possible scenario, we could include an option to ask
the following question:

"What language is your PalmPilot in?"

then set the charset accordingly based on the user input.

Comment 8

[Katsuhiko Momoi]

I'm going to arbitrarily set TFV to be M7.
By then we should have some story on this from rhp.
Right, Rich?

Comment 9

[rthorne]

Putting Mr. Ray on this bug and taking myself off.

Comment 10

[rhp (gone)]

Sounds reasonable to me...the world is a different one from the time of this
bug so this is something we have to keep on the radar screen, but when we get
to the point of thinking about building this functionality, then we need to
keep this on the radar screen.

- rhp

Comment 11

[lchiang]

Since this has to do w/MAPI, phil suggested I cc: [e-mail].

Comment 12

[Katsuhiko Momoi]

It turns out that under 5.0, all Address Book data - whether
they are from LDAP or personal Address folders - are stored in UTF-8.
This means we need to do the UTF-8 to local charset conversion
for personal AdBook folder synching as well.
Should we file another bug for that or should we subsume that under
this one and correct the Summary line?
Related question is: we need to find out if there has been or will be
any change in the data charset architecture for (recent) localized
versions of Palm Pilot. Does anyone have a contact at 3 Com's Palm
Pilot division?

Comment 13

[rhp (gone)]

This will be a bug that I track for whoever does the hotsync work.

- rhp

Comment 14

[Phil Peterson]

Palm sync and LDAP replication are both "out" for Seamonkey, so moving this to
the helpwanted list.

Comment 15

[lchiang]

Moving target milestone to "future" to be reviewed at a later time

Comment 16

[Katsuhiko Momoi]

QA contact to marina when/if this gets worked on.

Comment 17

[Thomas]

has anything happened on this since then? (bug cleaning)

Comment 18

[Wayne Mery (:wsmwk)]

(In reply to comment #17)
> has anything happened on this since then? (bug cleaning)

INVALID (obsolete, per bienvenu "refers to stuff we did in 4.x")