gnome database/addressbook/idl -- something more concrete

[stephen farrell <stephen farrell org>]

Here's some interface definition ideas... based heavily on BBDB.  Also 
based heavily on the suggestions by tom tromey
<m190s8szle.fsf@creche.cygnus.com>.

What's here:

o Some pseudo interface code that suggests a underlying mechanism for
  address book database.  This is just the programming
  interface--various user interfaces cann communicate with, and
  implementations can be written to conform to this api.
o I've attempted to add some possible "events" (see comments in next
  paragraph) which needs much more fleshing out.

What needs to be done:

o further flesh-out and organize (currently very naive...)
o write in idl
o events need to be handled--how?? one idea is a procedural database
  and hooks mechanism that would feel a lot like emacs... I don't know 
  much about the corba event model, that obviously is a likely
  candidate. 

bigger picture:

o i've been pushing a generalized database interface
  specification... the addressbook could be a special case of such.
o a lot of, e.g., bbdb functionality is (of course) at the ui
  level and is thus not represented here.  But I wonder where that
  line should be drawn?  e.g., bbdb has a function to look at headers
  and decide if there should be a new entry based upon these headers.
  while i think this belongs at the interface level, it would be a
  better world if this level of sophistication were generally
  available, as various mail and newsreaders ought to have access to
  it.  So where does it belong??


(Functionality idea: if one of the records was msgid's of email that
this person had sent you--it saves all email from someone who is
recognized in this database--then once one had a record, one could
quickly access all the emails you'd exchanged with this person...)

========================================================================
==> class database
// allow multiple databases easily unlike bbdb

variables:
	records					list of records
	user_fields				list of strings


	// some possible additions...	

	// one thing I don't like about bbdb is that it has a few too
	// many hard-wired aspects.  for instance, it is non-trivial
	// to make a new field be one of the ones prompted for when
	// creating a new record
	suggested_fields_for_new_record		list

methods:

// what is needed to make a new record?  this also needs to do some
// intelligent things to make sure that the record does not already
// exist. 
record record_new(??)
	triggers: already exists

void delete_record(record)

// this is a general-purpose search wrapper

(list of records) search(string value, string key (optional))

(list of records) search_name(string)

// and likewise for company, phones, email -- basically this is used
// for fast searches of hardwired fields.  use the wrapper above whcih 
// will call this if appropriate for searching custom fields

(list of records) search_custom_field(string)

// refiling is very useful if it turns out that two records are the
// same... 

void refile_record(record old, record new)


========================================================================
==> class record


	key					int	// ??
	fname					field
	lname					field
	AKA					list of fields
	company					field
	phone					list of fields
	address					list of fields
	email					list of fields
	url					list of fields
	notes					field

	// note that I don't see any value in embedding the
	// user-fields in the notes area as is done in bbdb
	user_fields				list of fields




void insert_field(field, string)	// string or object??

void update_field(field, string)

void delete_field(field)



// return possible completions for field (any field?)
list of strings suggest_completions(??)

// list possible fields (both built-in and added by user)
list of strings list_fields()




========================================================================
==> class field
// this (base?)class is used for both internal and user-created fields 
// (if, indeed, there is a distinction...)

	// list of regexps that input needs to match--good for phone
	// numbers, zip codes, email, etc.
	regexps					list

	value					string

	// etc...
--

Steve Farrell