Sync with gnome releases

[Michael Fair]

An deeper LDAP, Evo-Bonobo-Addressbook, and
Gnome-Addressbook "education" are certainly in order.

As far as exporting goes, I believe that being able to
export addresses to the vCard format should be sufficient
for operability with most applications worth their salt
these days for managing address info.  If you are trying
to do a Quicken export or some other financial app export
I think that is going to be much more difficult but again
is miraculously saved by our illustrious Bill Gribble's
modular architecture.

Linas mentions unreliability of public LDAP servers as
grounds for not using them.  I completely agree that we
cannot and must not relay on the public servers for our
address contact management needs.  However that says
absolutely nothing about the LDAP technology itself, nor
its usefulness in the private environment for the storage
of information that has some authority that takes
responsibility for the data's integrity (like an
individual or a companies IT department).

LDAP was designed as a Lightweight Directory services
architecture, it was designed for lots of reading and
very little writing to the storage tree, and it was
intended to be run as distributed application across
an entire enterprise on multiple servers for serving
data.  It does that well.  I expect the LDAP tree to
contain the current address and contact information,
while GNUCash retains just the unique DN used to
reference that person.  GNUCash would then get that
information from the LDAP server each time it required
it.  Yes this makes reports difficult to manage, but
as will show you below, this is solved by the module
interface Bill Gribble is designing.  If GNUCash would
like to cache that information so it doesn't have to
query the server all the time for it I would think
that's reasonable, as long it allowed for an explicit
reread of the data from the LDAP server (I could see
lots of dialogue boxes and flag options to get the
desired default behaviour the user would like to have).

To move forward we really need to define what problem
we are trying to solve and where we envision each piece
of the data coming from.  I believe there are a certain
set of assumptions that we need to standardize on before
we can start talking apples to apples in terms of needs.

For instance, as a home user, I probably won't need
much addressbook functionality except to store the
addresses/phone numbers of vendors I pay my bills to,
and maybe those people who pay/owe me money.
I will most likely not have a need to integrate this
information with my other contact/address databases.
Although it would be nice if it did, my palm pilot
and evolution application serve my real contact
management needs.  In this case, a GNUCash proprietary
storage architecture would be acceptable.  This would
match all currently known consumer level financial
applications that I am aware of.

However as a Small Business owner, (I'm not even thinking
Enterprise level yet) I absolutely am going to want
several kinds of applications accessing this data.  If
only so I can send Christmas cards to all my clients/vendors.
(I choose this example because it meets the requirement of
shared data, and is clearly outside the scope of the GNUCash
projects goals).

Linas brings up a good point of data integrity.  However,
I do not believe the GNUCash application can be solely
responsible for the integrity of my data.  His example
illustrates how a central system was relied upon for
accurate data and failed at that task.  However, the
proposed solution merely shifts the single point of
failure back onto GNUCash.  I absolutely admire Linas'
desire to create the ultimate perfection in financial
accounting applications, and I believe that I as the end
user am ultimately responsible for my data integrity.  The
example case he mentioned implies that it was buggy software
that led to the problems, is GNUCash going to try and imply
that it is bug-free and can do a better job than the other
applications that have dedicated themselves to their specific
data management tasks?

In a business setting, it is perfectly reasonable to
require the backend datastore to demand certain GNUCash
specific attributes for its use if they are necessary to
attain the shared data they are asking for.  In the case of
LDAP it is entirely plausible (if not even desired) to create
a GNUCash object class for use in an LDAP tree which lets LDAP
administrators know what fields need to be present in their
schema for their data to be GNUCash capable.  An SQL server
could also server well as the final storage device.  In reality,
however, assuming GNUCash keeps its same trend, there will be
a GNUCash Contact Mangement API that deals with the
address/contact management abstraction.

GNUCash will be able to define the fields it requires to make
the financial wizardry work yet be flexible enough to coexist
with other data about that contact as long as the API accepts
and returns the apporpriate data.

Enter Bill Gribble's modules architecture as being the savior of
the day here.  Assuming we had a modular architecture in place,
this problem becomes very easy to solve.  Simply create multiple
"Address/Contact" backend/frontend modules that engine uses.
As long as the API interface is defined, then on the backend these
modules will have a specific set of functions to implement and a
specific set of data to return.  On the frontend, these modules
will have a specific set of functions available to them from the
backend which will return certain data which they can then be
responsible for displaying or outputting to the appropriate place.

It could even see this API evolving into a more generic standardized
API that many applications code to when they want to use address and
contact information.

The one complication with this model that I see is
that it becomes difficult to use the Evo-bonobo
component as the sole interface for both GUI and backend.
Since the engine wants to be in the middle, and indeed
may require certain things be in the middle to trigger
events for objects that may have asked to be notified if
the address information changes, something will need to
be done to please the engine (I imagine that just a small
stub backend module would suffice but I can't be certain).

I would forsee the following immediate backends being useful,
1) Home/Business users who are single users, do not
    care about data sharing, and do not have/want
    Evolution will use the home grown modules.

2) Same as 1, but do have Evolution can use the
    "Use Address book module from Evolution" option.

3) Multiple users who do not care if the data is
    available to other applications can use a GNUCash
    controlled SQL backend (probably as another few
    tables in the already existant GNUCash database).

4) Single Users who desperately want multi-application
    data sharing use a generic LDAP client, or SQL
    client module.  This module has the added management
    overhead that comes with having to outsource the
    data storage, but this is OK because they asked
    for it.  (I am on of these guys and prefer the SQL)

5) MultiUser installations who desperately want
    multi-application data sharing can use a beefier
    version of option 4.  Again more overhead, but
    again, they asked for it.

I keep thinking about the Linux kernel which gives
generic OS services to the end users.  In my mind
I keep seeing the GNUCash engine as really the GNUCash
kernel which has standardized hooks that it expects to
be met by backend modules, and standarized methods
that it expects its clients (the GUIs/CLIs) to use.

This model requires that the only real hard part be
defining what "Address/Contact Management" means to
GNUCash so that an appropriate API can be developed.

For instance, will GNUCash allow for a virtually
infinite number of customized fields that can be
manipulated?  This genericism seems only useful in
searches and report generating, that usefulness alone
could be enough to warrant support for such a feature.

Will GNUCash support multiple data types, or will it
limit its fields strictly to text.  I'm thinking that
supporting the MIME storage format might be a slick
way to include "other-than-text" data values, but only
if there were some clear "real-world" uses for such
support.  FOr instance, I would think that storing
a scanned image of a bill would be very useful to have
available and stored/visible inside of GNUCash.  Are
there other "binary" data values that people would
think are valuable enough to warrant generic data
storage support?

I hope this email helps to clarify matters and
continue moving us forward in creating the ultimate
financial machine, but not being on the inside of
having to actually implement this I am not sure that
I got enough of the issues currently on the table.

-- Michael --

> On Wed, Jul 18, 2001 at 06:39:27PM -0500, Bill Gribble was heard to
remark:
> > On Wed, Jul 18, 2001 at 05:49:34PM -0500, Linas Vepstas wrote:
> > > > What if we used LDAP directly? That would allow us to use
Evolution's
> > > > GUI as a bonobo component, but would also allow access from
Evolution
> > > > directly, and from other applications that also support LDAP.
> > >
> > > Uhh, I suppose, in some certain sense, that would be ideal.
Presumably,
> > > we can tell evo-bonobo that 'here we are, we're an ldap server at port
> > > 33889', and hopefully evolution supports editing and update to ldap
> > > servers.   I haven't successfully used evolution ldap.
> >
> > I interpreted Dave's request the opposite way: gnucash is an LDAP
> > client, just like Evolution, and they both work with the enterprise
> > LDAP server.  Request info, update info, etc.
>
> Uhh, no, just the opposite.  As stated in other note, basically,
> you can't trust data in the public servers, and private servers are
> a hassle to administer, and also raise both data management and
> data integrity issues (viz, if someone whacks/forges data in the
> LDAP server, and gnucash was using this data to mail invoices...
> ouch).  So gnucash needs to store its own private copy of audited,
> vetted, trusted, 'gaurenteed correct' address data within itself.
>
> But it would be nice to use an evolution bonobo plugin to view
> that data, and so evolution would act as 'client', gnucash
> as 'server'.
>
> --linas
>
> (p.s. the data integrity issue is real. My ISP had a problem like
> this, mishandled billing for nearly 3 months.  It took customers
> a month to receive their bank statements, notice something was
> wrong, start complaining to the ISP, before things started getting
> fixed.  So if your ldap server is serving up corrupt data, don't
> assume you'll just catch it in an hour or two; it could go
> undetected until a lot of damage has been done.)
>
>
>
> --
> Linas Vepstas -- linas@gnumatic.com -- http://www.gnumatic.com/
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
>