Sync with gnome releases

[Linas Vepstas]

On Wed, Jul 18, 2001 at 01:10:02PM -0800, Stanley Long was heard to remark:
> Bill Gribble wrote:
> > 
> > On Wed, Jul 18, 2001 at 01:03:10PM -0500, Linas Vepstas wrote:
> > > Now, of course, I dunno what happens if/when we decide to manage accounts
> > > and vendor lists with e.g. the gnome addressbook.
> > 
> > Unless it can be used in a totally GUI-free way, I don't think it's a
> > good idea to get tied to the Gnome address book.  


Well, I'm grappling with two seperable issues: the data import-export 
problem, and the gui problem.  Let me list the spectrum of solutions,
so we can try them on for size:

A: 100% homegrown: gnucash stores adresses in internal format, creates
   own gui to view/edit them (presumably part of account info.)
   + no depndencies
   - need to write export routines

B: use e.g evolution addressbook GUI, but store adrressses in internal
   format.
   + seriously slicker appearence, more features than A.
   + solve some of the import/export problem by using evolution 
     components.  (e.g. get LDAP import, printing output.)

C: use homegrown gui, but store adresses in 'evolution' format.
   + works good for single-user, desktop mode
   - gui aint as pretty as B
   - nightmare data management/security problems with multi-user,
     server system.

Thus, you see my preference for B.  I'm trying to be reasonable, it
just seems that B is the best choice.  I mean, A is good too, but
its depressingly stale.
   
> > I think it's good to
> > use shared backends where possible, but in this case I think this
> > means attaching to the same data stores the Gnome one uses rather than
> > actually using its API.

Couldn't disagree more. Evolution's data stores suck.  Basically, I
cannot share my evolution addressbook, or any subset of it,  with anyone 
else in the office.  It has neither p2p nor client-server interfaces. 

An address book for gnucash home users isn't that interesting, but 
for a small office/business, having good address/contact info is vital.
But for office/business, that probably means multiple users, which
means that the data storage must be centralized or p2p'ed, and not 
locked to desktops.  And then the security, access permissions, 
authentication, etc. ogres raise thier heads. 

Maybe I'm wrong, maybe someone from Ximian will pop up on this mailing
list and tell me that they've added MS passport features to the address
book, and they've got a postgres backend for it, and a security / 
authencitaion model for it, or maybe a really slick p2p shared desktop
feature.  But I doubt it. 

So when I say this, I really do mean 'use the evolution gui', and 
I do mean, 'use the evolution data handling interfaces to solve the
printing and data import/export issues. '  I really don't want to 
store gnucash addressbook data in a berkley-db file in some remote
directory.  I want to have hooks in the data so I can cross reference
to gnucash accounts.
  

> > If it's really important to embed the Gnome/Evolution addressbook, we
> > should at least have a GUI-independent layer that would allow other
> > front ends to be used.

Yes, I agree. 

> > I'm sort of itchy for a gui-free gnucash in case you can't tell :)

Hmmm ... does this mean that your itching to be able to generate
html reports from the command line?  That would be way cool!  I could 
write a cron job to email me my account balances every morning.  
Enterpriseing web site owners could use the gnucash report subsystem
as a cgi-bin.  (I've already had a private request for this, some folks
who are working on a backoffice solution for travel agencies.)

--linas


-- 
Linas Vepstas -- linas@gnumatic.com -- http://www.gnumatic.com/