Customer vs Company

[plussier at mindspring.com]

In a message dated: 03 Apr 2003 12:58:24 EST
Derek Atkins said:

>plussier at mindspring.com writes:
>
>> My understanding was that this was going to be an embedded database 
>> though, not using the postmaster db server from PostgreSQL.
>> 
>> Is this incorrect?
>
>Yes, you are incorrect.  The re-written PG Backend uses Postgres.  The
>plan is to re-use the re-written PG SQL code and use an embedded
>MySQL.

So there won't be a PG server running?  I think I'm gettig confused :)

>Sure, but you can put an LDAP front-end on top of a SQL database.
>Just translate the LDAP queries into SQL queries.

Correct, which is exactly what I was alluding to below.  However, if 
it's an embedded db, how would you get the external LDAP<->SQL 
gateway to talk to the db if GnuCash isn't running?  And, this would 
also imply that if GnuCash is running, it would be capable of 
answering SQL queries from external apps.  I don't get the impression 
that this will be the case with the embedded db.

>> Now, if there's going ot be a full-blown db back end, then it's 
>> entirely possible to poll this data from PostgreSQL and populate an 
>> LDAP server if that's what the business wants to do.  That would be 
>> the ideal solution, since it doesn't involve GnuCash at all, it's 
>> totally optional, and allows anyone without knowledge of LDAP or SQL 
>> to live a happy life :)
>
>Eh???  If you have to do this, then LDAP is even MORE broken than
>I suspect.

How so, all I'm saying here is that with a db server as the back-end 
of GnuCash, that you could have an external program like a 
perl-script, run from cron to poll the db periodically, extract the 
address data from the db using SQL, then reformat the data to 
populate an LDAP server.  Those needing to access the address data 
from something like a mail client can just point their client at the 
LDAP server and never need to know where or how this information gets 
into LDAP.

The LDAP protocol is not SQL, you still need some gateway to get data 
from an RDBMS into an LDAP server.  I don't see why this is 
considered "broken".

>> But, as I stated, my understanding was that it was going to be an 
>> embeded SQL engine, not a full-fledged db server.
>
>Submit code.  I'm not going to write one-line of LDAP code myself
>without a LOT of financial incentive.

Before I can submit code, I need to understand what it is I'm 
submitting code to do :)  If it's writing code to query PostgreSQL to 
extract data and place that data into an LDAP server, that's not 
difficult.  If it's parsing an XML file to place the data into an 
LDAP server, that's not difficult.  If it's both, not difficult, just 
twice the amount of work.

If I'm submitting code to make GnuCash to talk to an LDAP server, 
that's a different ball of wax.

Btw, I get the sense that you're getting defensive for some reason,
and I'm not really sure why.  We're merely discussing some ideas,
definitely not requesting/demanding you write anything.  I apologize
if I've come across that way, or somehow unintentionally offended you.
-- 

Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE

	It may look like I'm just sitting here doing nothing,
   but I'm really actively waiting for all my problems to go away.

	 If you're not having fun, you're not doing it right!