Sync with gnome releases

[Paul Campbell]

On 2001.07.19 02:36:46 +0100 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.

Wouldn't that be where LDAP authentication comes in? I'm developing an MIS
website at work, and I use our LDAP server for authentication to access the
site. The web server (apache) has to authenticate to the LDAP server before
it can auth. any users to the site. Even then I can't update any of the
data in the LDAP repository, it's a read-only account.

I haven't looked into this, but couldn't you extended the schema for the
LDAP repository and protect those fields from being accessed (read-only or
otherwise) by users without the appropriate clearance?

> 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.
> 
> 3) And if have to put the account manager's name in a kvp-frame, then
>    where do we draw the line?
> 
> 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.

Let me check. You *are* both refering to LDAP support as an *option* that
individual installations can use or not as their expertise/requirements
require/allow?

--
Paul Campbell