Re: more on the addressbook database specfication

[Tom Tromey <tromey creche cygnus com>]

Stephen> (Hm... no response about my previous post on this
Stephen> subject... I hope I didn't say anything to offend anyone?  if
Stephen> so--it wasn't intended!!)

I don't know why nobody responded.  Maybe nobody understands it (:-)?
Or nobody cares?  Deafening silence has (largely) been the response to
my IDL proposals as well.

I've been too busy -- that's my excuse, and I'm sticking to it.

I've read through your IDL, and I have some comments.  This is kind of
rambling, because it is late, and because a lot of the thinking was
done as I was typing.


First, I don't have a feeling for the expense associated with creating
a new CORBA object.  I have 6,700 entries in my BBDB (and that really
isn't many).  Will creating a new record object for each one be too
expensive?

If so, then that suggests different interfaces.  Instead of contacting
the record itself, you would manipulate record ids, and contact the
associated database to make modifications.

(I prefer your interface if feasible.)


Here's a random (but intruiging?) problem with passing regexps around:
there are multiple regexp syntaxes.  Worse, some forms of regexps
(e.g., Perl's) are notably more powerful than others, so syntax
translation is not always possible.

One can imagine various complicated solutions to this problem (regexp
servers?).  Or simple ones (least common denominator).  Still, it is a
problem.


There's also nasty character set issues.  I imagine we'll just run
away from these for a while, and then eventually settle on some
Unicode encoding.


You write:

// also note that everything /could/ be a user defined field (with
// fname, lname, etc just happened to be predefined)... and I've
// been thinking about this somewhat seriously... 

I think this is definitely the way to go.  While BBDB points to the
functionality that should be available, I think we shouldn't let it
drive our interface design decisions.  BBDB does have flaws (the
people working on the next generation BBDB plan to address some of
these, I believe.)

The alternative to hard-coding some fields is to document customary
field names and their uses.  I think this is perfectly acceptable.


  void insert_field(string field_name, string value);
  void update_field(string field_name, string new);

Why are these different?


  string_seq list_fields();

I think it would probably be more useful to attach this to the
database and not to the record.  That is, I think it is more useful to
get a global view of all defined field names.

Maybe both are required?  I'm sort of fuzzy here...


Maybe a field should be a union, with special types for things that
really make sense to be special (address, phone, ...?).


About these:

  record_seq search(string value, string field); 
  record_seq search(string value);
  record_seq search_name(string value);

If there are a very large number of records (e.g., suppose I ask for a
match of ".*"), then it will probably be much more efficient to use
iterators and not simply return a list.

What are the VALUE arguments in these calls?  It does make sense to
search for partial matches.  E.g., mail-abbrevs in Emacs has a cool
feature where you can type in a partial name or email address and ask
for completion.  This is definitely something that the database must
support.


I don't think it makes sense to make a record without adding it to the
db.  So record_new and record_add should merge.


I think refile_record isn't the best name.


My proposed interfaces include some iterator stuff (in the GnomeEdit
module -- but we could easily break it out into its own module).


// o a lot of, e.g., bbdb functionality is (of course) at the user
//   interface 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??

I also have a hard time drawing these lines.

One idea is to separate between the Service and the UI (aka
"Application") layers.  Something like BBDB would export both
interfaces.  Other implementations might keep them more distinct.

I don't know how well this would really fare... sigh.

Another choice is to just post a message to the database:

    oneway void noticed_item (string who_i_am, dictionary what_i_found);

Then you leave the decision up to the database.  A mail reader would
run (fakey syntax):

    database->noticed_item ("MailReader1.0", { "name", "Tom Tromey" ... })


Another, more generalized, way to handle this would be to post this
information as an event (either via my proposed GnomeObservable
interface, through my proposed GnomeEventManager service, or via the
standard Event Service -- depending on what we decide to do).  Then
the database manager would just filter out the events it cares about.

I.e., instead of direct communication, it would communication by a
kind of indirect rendezvous.

The nice thing about this model is that *any* app can filter out the
messages -- we don't have to plan in advance who to send this stuff
to.

I think this is my preferred method.


// (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...)

This could be implemented in the database if mail/news readers passed
the msgid in the dictionary to the "noticed" event.


Hopefully this helps.  I think we're going to have to iterate like
this on basically every interface we define.  And we'll probably only
discover some flaws while implementing.  Still, we have to start, or
we'll never get anywhere.  Thanks for taking the time to write up your
proposal.

Tom