On 2/22/07, Chris Frey <[EMAIL PROTECTED]> wrote:
>
> > b) the created DN values are missing a qualifer prefix (cn=) and have
> > an extra space before the comma, it looks like:
>
> Fixed among the overhaul.
Alas, the space is not fixed. :-/ Using a basic commandline, it looks like:
# Contact 0x5147561c, Goat Hill Pizza
dn: cn=Goat Hill Pizza ,dc=foo,dc=com
cn: Goat Hill Pizza
Still a space after 'Goat Hill Pizza ' -- I checked my address book by
hand just to be sure there wasn't a space on the device. It's clean.
> > c) I store all contacts without a given name, only the surname and
> > mobile is filled in (what I call SIM-friendly format). The resultant
> > LDIF uses 'givenName' instead of 'sn' by mistake. This might be a more
>
> Try the new -C givenName.
Still broken -- btool is extracting the LastName field and inserting
it as givenName; it smells like some sort of mixup in the internal
mapping in some barry code.
./btool -c dc=foo,dc=com -m "sn,LastName,LastName" -m "givenName" > foobar.txt
# Contact 0x5147561c, Goat Hill Pizza
dn: cn=Goat Hill Pizza ,dc=foo,dc=com
cn: Goat Hill Pizza
displayName: Goat Hill Pizza
mobile: +14156411440
objectClass: inetOrgPerson
Notice no 'sn' attribute -- I can 100% verify that the phrase "Goat
Hill Pizza" is stored in the LastName field in my Address Book. If I
don't unmap 'givenName', it appears in that attribute by mistake.
It's more than LDIF though:
./btool -d 'Address Book' | grep Goat
FirstName : Goat Hill Pizza
I can't provide a screenshot, but on the device those words are in the
3rd field down, "Last", on my Pearl. The field data syncs properly
with SyncJe/Mobical.net (online SyncML provider), my data is properly
mapped to the LastName field in Mobical.net's database (so SyncJe is
working properly).
> > objectClass: inetOrgperson
> > objectClass: organizationalPerson
> > objectClass: person
> > objectClass: top
>
> As John mentioned, fixing some of the schema issues may require our
> own Barry or Blackberry schema. This would be useful for storing
Agreed, but the above fields won't -- they should be there all the
time. This is a basic LDAP schema thing, nothing Barry specific. If
the LDIF file includes inetOrgPerson attr it has to include all the
parent object class attributes. Depending on your "other" tool (like
if you import the LDIF to an LDAP server, then point various webmails
- squirrelmail, hastymail, horde, etc. - at it) they may search on
&(objectclass=person) or &(objectclass=inetOrgPerson) and so forth.
So, all parent should be included in the output for maximum
compatibility.
(again, at least as I understand it - if someone knows better, holler!)
> > e) one contact had some odd output in the postalAddress, her entry
> > looks like (some parts XXXXX'd for privacy):
I'll have to play with this some more -- I cleaned up that contact
data to only have the information in the Home address (and not Work),
and with the newest btool nothing is coming out! The address data that
is -- the basic contact data is being exported. From what I understand
I have to map all the address fields by hand now, right? Ugh.
-te
--
some live, some die
in the way of the samurai
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel
