Customer vs Company

[plussier at mindspring.com]

In a message dated: 03 Apr 2003 15:03:19 EST
Derek Atkins said:

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

Ahhh, okay. I get it, so you're ultimately going to ditch the XML store
completely in favor of a real database where the same SQL code gets 
used regardless of whether it's an embedded db or not.

That sounds good.  (though I once argued in favor of maintaining the 
flat text file, all those reasons are satisfied if I can dump the db 
to a file for back up purposes, but that's a different horse, which 
I'm pretty sure is dead now :)

>> How so,
>
>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?

I don't actually know that you can't.  As I said, I'm in the process 
of mucking with LDAP now, and it happens to be the OpenLDAP 
implementation which uses a Berkely DB backend.  I don't know that 
it can't speak SQL to a SQL db server, but that's not a model I've 
ever seen (though, you'd think someone, somewhere, would have thought 
of this and tried it out by now :)

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

So, what I think you're saying is that you don't really like LDAP? ;)

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

Agreed. 100%.  But how do we do that?  Evolution speaks LDAP (or claims 
to, I playing with it right now against my corp. LDAP server and I'm 
1 for 10 queries right now!) but not SQL.  GnuCash is going to speak 
SQL, but not LDAP.  So what kind of intermediary solutions are there?

We could hack Evo to speak SQL, but I don't see much point in that, 
and I'm not going to volunteer for that one :)

We could hack GnuCash to speak LDAP, but we seem to all agreed that 
this is a bad idea. 

We could write an interemediary program which gets run from cron 
periodically to extract data from SQL db and dump it into an LDAP 
server.  This seems to be the easiest solution, since it places no 
requirements or additional dependencies on anyone.  The caveats would 
be that to use this method would require running the full-blown db 
backend version of GnuCash so that the intermediary could access the 
db.  I don't expect this to be a problem in a business/multi-user 
environment.  And if they're cabably of setting up PostgreSQL, then 
they're likely capable of setting up OpenLDAP.

While I too, loathe the concept of duplicated data stores, unless 
someone knows of an LDAP server which speaks SQL I don't see any 
other choice.

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

Well, I don't think that's overly difficult.  If you want to use 
GnuCash, and you want to access it's data from external clients which 
are LDAP enabled, we can have an external mechanism which replicates 
the data.  Not optimal, but it solves the problem.

I'll even volunteer to write that part, as long I can do it in perl :)

(of course, I don't hear a lot of people screaming for this 
functionality anyway :)
-- 

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!