gnokii-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: phone number and/or vcard handling bug?


From: Zrubecz Laszlo
Subject: Re: phone number and/or vcard handling bug?
Date: Tue, 21 Jun 2005 10:26:43 +0200

2005-06-20, Pawel Kot wrote:
> The error message is bogus.
OK I see. so it's not a problem. :)

> > There will be an entry in my phone with correct name and the NOTE entry,
> > but without the others :(
> 
> Indeed. That's because gnokii supports only subset of the entry types.
> And I'm afraid your phone neither supports all of them.
Of course not, but what about the numbers and emails, etc?

> > - the TYPE declaration like: 'TEL;TYPE=CELL;X-EVOLUTION-UI-SLOT=3:' is
> > unknown fro gnokii. gnokii is only accept: 'TEL;CELL:' format.
> 
> That's right.
Well, maybe the vcard from evolution is broken too, but this format is looks OK.

> > - the number format like: '+36 (20) 555-2222' is invalid in gnokii.
> > gnokii is only accept '+36205552222' format.
> > (This 'bug' is the same when I'm try the ldif format)
> 
> That's not a bug. That's a feature. This is the only format that the
> phone accepts a number format. And I think it is not good to let
> gnokii to do the conversion, because it may be buggy. It's better to
> leave it to user.
But the main feature of vcard import that we can put the phonebook data
from other applications like evolution and others. Of course we are
using separator characters like '/', '-', '(', ')' and space for better
reading. 
The concersion is very phone specific, so if I have more than one phone,
or I just upgrade my phone I had to correct all of my other phonebook
sources to keep compatibility with my new phone? It is nonsense.

It's ok, that the conversion can be buggy, but what can't? What if we
can force the conversion with an option? I think the inport feature is
useless witout the phone specific conversions.

> I was thinking about more general support of the vCard format, bu tI
> haven't found any library that would be still supported and easy to
> use. Any hints for that?
Well, I don't know about C libraries, but I found these:

http://www.imc.org/pdi/
http://www.ietf.org/rfc/rfc2425.txt
http://www.ietf.org/rfc/rfc2426.txt


And what about the ldif import capabilities? There is any compatibility
problem like this with vcard?

-- 
Zrubi.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]