On Tue, 2009-10-13 at 18:47 +0200, Lars Schade wrote:
> >On Sun, 2009-10-11 at 23:52 -0430, Patrick O'Callaghan wrote:
> >> On Sun, 2009-10-11 at 20:46 +0200, Lars Schade wrote:
> >> > To illustrate the issue I start with a local addressbook and add a new
> >> > contact using the evolution GUI say for the Berlin Office of a company
> >> > called "The Big Wheel", and I fill in the name dialog as given name
> >> > "Berlin Office" and as family name "The Big Wheel". It is displayed as
> >> > "The Big Wheel, Berlin Office" exactly what I want. I can use the this
> >> > information to automatically generate address labels with openoffice,
> >> > everything perfect.
> >> I'm not very knowledgable about LDAP, but it looks to me like you're
> >> using it incorrectly. Using the Name subfields (First, Middle, Last,
> >> Suffix) to stand for Office/Company is bound to lead to trouble, if not
> >> within Evo then elsewhere you might want to use LDAP records. The field
> >> names are there for a reason and some apps attach semantic meaning to
> >> them. For example a Name with a space in it can legitimately be
> >> interpreted as two names, where the second one can be represented by an
> >> initial. This makes perfect sense for given names and makes no sense for
> >> the name of a company.
> >> You should reconsider how you're using LDAP. The key thing to remember
> >> is that a "contact" is meant to represent a person, not a company.
> > All this is true - as a user you are over a barrel however. I spend a
> > ot of time working with vCard data - to be blunt: the vCard (RFC2426)
> > spec is lame. But it is everywhere and what we [sadly] have to live
> > with. A vCard represents a *PERSON*, there isn't any good [or
> > standard] way to represent an Enterprise (company, organization, ....).
> > The "FN" is the name of the vCard and corresponds to the "CN" (common
> > name) attribute in LDAP. That is OK. *BUT* the spec also *requires*
> > "N" which is a composite value of "Family Name, Given Name, Additional
> > Names, Honorific Prefixes, and Honorific Suffixes" Of course that makes
> > no sense for a vCard that isn't a contact - but the client *must* shove
> > something in at least on of those fields. This isn't Evolution's fault
> > - the spec is retarded. [The required attributes for a vCard are: FN,
> > N, and VERSION. Many implementations have a tacit requirement for UID
> > as well]. Evolution's internal data model is [reasonably] based on the
> > vCard spec as is that of Thunderous Crap, KDE's PIM (is it still called
> > Kontact?) , as well as most other PIMs. Outlook has the same problem.
> > You need to use a "real" groupware client to avoid this lameness.
> Thanks for the answers, I was afraid the problem was a bit more basic.
> On the practical side: Is there a workaround you know of?
No.
> Or how do you handle contacts that are not real persons?
Badly, or not at all. I use WebDAV to provide access to address books,
not LDAP, but I just disable access to the Enterprise folder and only
allow PIMs to see Contacts.
<aside>
I think I can make a reasonable philosophical argument that this is
correct anyway - in reality people communicate with people, not with
conglomerations. So there should be a Contact object in the groupware
system for whoever you actually talk to rather than using an Enterprise
object as a stand in for many people [doing so violates every principle
of good customer relationship management - Hug your customer! :)] But
in reality, especially in situations like AP & AR departments this
doesn't really work. I've not found any good way to make any PIM
behave in a manner compatible with an AP/AR department mindset.
</aside>
> On the theoretical side: The problem really only arises, once I switch from
> a local addressbook to LDAP.
Sort of; you just don't notice it with a local addressbook. The fields
are still being abused semantically; for large long-lived databases
(relational or not) that is a problem.
> There is a basic mismatch between the
> data model in Evolution and the way data is stored in LDAP.
Not as much as you might think. There is actually a pretty good
correspondence between vCard and LDAP in how attributes are handled.
Your problem is that the evolution schema is based on vCard which is
meant to represent a Contact; it stuffs the attributes accordingly.
> But the
> problem could be solved by adapting the evolution schema for LDAP in
> such a way that the different name parts are stored separately rather than
> being reconstructed from the CN entry in the LDAP database. Or is there
> any reason not to use separate attributes for all the vCard name
> components?
No, there is no technical reason to do it in one attribute. But LDAP
support in most clients, including Evolution, is pretty hackish
(speaking as an LDAP guy who is an LDAP admin). The schema is not
configurable, and no client I've met [other than Turba, if you consider
a web app a client] has real schema configurability. Ideally it would
be configurable per-address-book - but that is probably a lot of work
[for a developer]. Also I have no idea if the LDAP code supports
multi-valued RDNs which would be the best way to automatically construct
the DN for an LDAP address book.
Our solution has been: don't use LDAP for addressbooks. We did for
years. It seems like an ideal solution but in fact doesn't work that
well:
(a) Evo is the only client I know of with LDAP write support
(b) there is no standard schema, so different clients can't agree
(c) Many clients [Thunderous Burp for example] have ***horrible*** LDAP
support. Thunderous Burp uses a schema that must have been designed by
a crack head; but then TB's (what an appropriate name) entire address
book is just so crappy I don't know how anyone can tolerate it.
The better solution is to use a groupware server for shared address
books and contacts, etc... and leave LDAP for sharing accounts and
aliases - which it does well and probably already contains for other
reasons.
But even that won't get you around the inherent RFC2426 limitations.
The hCard spec contains a clause that states if the ORG and FN values
are the same than the card represents an organization and not a contact.
That isn't a terrible standard to stick too, but it doesn't help with
what to stick in "N". OpenGroupware gets around this by just stuffing
"N" with a proprietary identification string (like "OGo1234567"). I'm
not sure if that is "correct" or not, but it works OK.
In the Evo LDAP support is the "ORG" attribute of the address book
mapped to an LDAP attribute? ("o" I'd assume?) Off hand I don't recall.
_______________________________________________
Evolution-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/evolution-list
