Customer vs Company

[Derek Atkins]

plussier at mindspring.com writes:

> 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 :)

Sorry, I was unclear.  The re-written PG backend uses Postgres.
That implementation will use a full-blow PG SQL server.

The longer-term plan is to re-use that code to _ALSO_ support an
embedded MySQL backend, and hopefully make the embedded-mysql be the
"default" storage mechanism.

> >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.

Obviously if you use embedded-mysql you don't.  But then again if
you're using XML you don't either. ;)

> >> 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".

It's broken that you have to copy the data out of the SQL database and
INTO an LDAP database, rather than having the LDAP server just create
a SQL query everytime it receives an LDAP query and format the
response data appropriately.

The "broken" part is the fact that LDAP needs its own data store,
rather than being able to perform a lookup in some other (SQL) data
store.  The DNS (which is another example of a directory) is backend
agnostic.  There are certainly DNS server implementations that sit
on top of a SQL database; why can't LDAP do that?  Why do you need
to copy the data?

> >> 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.

I have no clue what you want it to do.  You tell me.

> 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.

I just think LDAP is a bane on society and should be killed as quickly
and efficiently as possible.  It's the WORST of all worlds possible.
Security was an add-on and not well-considered.  It uses ASN.1 in all
the worst ways.  It really should just die, and I'll be dancing in the
streets when it does.

OTOH, I agree that getting evolution and gnucash to share a contact
list is a Good Thing....  However I do not want to make GnuCash depend
on Evo (and I don't think Evo should depend on GnuCash).  So we need
to find some intermediary..

However GnuCash already has way too many dependencies, and I'm
hesitant to add any more that don't provide any visible benefit to a
user of GnuCash that DOES NOT use evolution or some other system.  So,
anything that follows that route is going to have to figure out some
plug-in architecture....

I leave that as an exercise for the reader. ;)

> Seeya,
> Paul

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available