Sync with gnome releases

Dave Peticolas dave@krondo.com
18 Jul 2001 18:56:09 -0700


On 18 Jul 2001 20:36:46 -0500, Linas Vepstas wrote:
> On Wed, Jul 18, 2001 at 06:14:17PM -0700, Dave Peticolas was heard to remark:
> > > I guess we're still on a separate page.  I envision gnucash as an ldap
> > > server, and things like evolution would be the ldap client.   The details
> > > of storing the data are up to gnucash, and not some distant server.
> > > Why is this?
> > > 
> > > -- I want to associate specific address info with specific accounts.
> > >    So I need to store at least one or more "cn=" with gnucash data.
> > 
> > It seems that ldap entries have uids -- why not associate in the
> > other direction? 
> 
> 1) Because I don't think you can trust LDAP servers, whether public,
>    or privately administered.  Once you've set up gnucash account info,
>    you don't want someone getting into your data and changing addresses
>    on you.

Well, if GnuCash was an ldap server, it could be changed from the
outside as well, so I don't see your point here. Also, the fact
that it can be changed outside of GnuCash is a *feature* since
it lets people use their favorite contact manager which supports
ldap.


> 2) Gnucash's ideas of what's important to store may differ from the 
>    default templates on the LDAP server.  e.g. maybe we want to include
>    the name of the account manager and thier phone number as part of the
>    address data.  I'm not sure that ldap can really deal with this 
>    kind of free-form, "kvp-frame" style data.

It seems we need more information about what ldap is capable of.
I was under the impression that ldap was very flexible, much like
our kvp trees, but with fewer data types, possibly just strings.


> 3) And if have to put the account manager's name in a kvp-frame, then
>    where do we draw the line?

We don't put that in there, we just put in the ldap record's uid.


> 4) It makes queries hard. Imagine a report 'show me money owed to 
>    everyone in chicago' (or zip code 60601).  You'd have to issue
>    both LDAP and postgres queries, rank and sort and fold and spindle
>    the results before displaying them. Yuck.

> > I think it would be a mistake to make gnucash a
> > an ldap server. Why should we reinvent openldap?
> 
> Who said reinvent? In your previous email, you yourself said 'we could 
> add ldap support'.  I assume that meant coding to API's.

Ok, I should have said reimplement. I think we should use openldap
instead of recreating its functionality inside gnucash. OpenLDAP 
definitely exports a client API, which is what I was talking about
in the first place, i.e., using openldap's implementation to make
GnuCash an openldap client as opposed to relying on evolution. Now maybe
it exports enough to make it easy to provide our own server, I don't 
know, but I think it's a mistake to recode what's already available.

dave