Re: Database intergration with GNOME?

[Tom Tromey <tromey creche cygnus com>]

Shawn> Well, if you want to use an addressbook as an example, I would
Shawn> be interested in hearing it. ;-)

Ok.

The approach I would take would be to define an IDL interface to an
abstract address book.  It would provide whatever methods and
functionality I think an address book might ever want.

For instance, I would assume that an address book is made up of a
sequence of records, each record representing a single "person" (or
company, or ... -- anything that has an identity that should be stored
here).

Each record in the database would have some predefined fields, and
also the ability to store arbitrary key-value pairs in a dictionary.
(keys and values probably being strings, for simplicity)

The address book itself would provide various ways to ask questions
about the database, iterate over its contents (or subsets thereof),
and add/modify/delete records.

It would define events and confirmation actions for "interesting"
things.


In my design, some of this would expressed directly in the IDL, and
some by convention in the docs (I prefer a simple event structure,
where events are just strings with associated data.  In this situation
you have to list the actual events separately).


For Aorta, I would use the C stubber to generate the server side stubs
for this new interface ("GnomeAddressbook").  I would write the
necessary server-side code to expose the Aorta internals as
appropriate.

For the client side, I would have Aorta talk to the event server
(TBD), and ask to be notified when an address "appears".


I would then modify my mail reader to talk to the address book
interface in some situations:

* When I type a partial email address (or name) and ask for
  completion, it would do a database search and present me with the
  choices (or just insert the completion if there is only one -- or
  insert all of the completions if I entered the name of a
  self-defined mailing list)

* When I read a new mail message, it would make sure the address book
  has the information about the author.  The address book might
  display this info somewhere (if I've configured it to).  This
  request is handled by posting an "I saw an address" event through
  the event server.

* When I reply to a piece of email, it might ask the address book for
  my preferred citation prefix for that person.  (Or maybe there is a
  Citation service that does this for the mail composer.)


If you're an Emacs user, this will all seem vaguely familiar: it is
VM/Rmail/Gnus, BBDB, mail-abbrevs, and SuperCite.  The difference is
that Emacs is a closed world: if it isn't in Elisp, you're out of
luck.

As I see it, CORBA's role in Gnome is to provide the tight integration
that exists inside Emacs, without forcing a particular implementation
technology on anybody.


I think a good eventual goal would be to include an ORB in Emacs
itself, so that existing Emacs modules could talk to Gnome apps, and
vice versa.  This would certainly make my life easier in some ways.

For instance, (and I owe Mark Galassi for this nice example), we could
hack the freed Netscape so that clicking on "mailto:" URLs would start
up `M-x mail' in Emacs.  (For me.  For others, it would run whatever
they've configured into GOA.)


Obviously, all this is a lot of work.  And in the absence of an ORB we
can really start using, we can't really work on the implementation.
But there are still things we can do today:

1. Make sure applications we write now are structured so that turning
   them into CORBA servers later isn't too difficult.
2. Work on the design of the services we want to provide by default.
   I believe a certain amount of design iteration on the interfaces
   can be done in the absence of actual running code.
   This task includes making a list of services to provide, which
   might also result in different design decisions for particular
   applications.

This is why I keep pushing my proposed initial interfaces on this
list.  I'm interested in getting the design process rolling -- I'd
much rather be actually working on the design than endlessly talking
about working on it.  (But at the same time I don't want to just start
checking in stuff that nobody else has had a say (or an interest) in.)


It would also be possible to use CORBA to separate the user interface
from the actual address book back-end.  In my example above I've
deliberately conflated Aorta and its back end, which is likely to be a
mistake.  I think the separation is pretty obvious once the above
makes sense.

Tom