Re: Your Opinions Requested

[Peter Williams <peter newton cx>]

On Tue, 01 Feb 2000 13:26:04 Sarel J. Botha wrote:
> I think balsa itself should just check for a .baslsarc, convert to
> gnome-config and delete .balsarc. The user doesn't even have to know about
> it.

So do I, but it's not necessarily that easy to implement :-)

I think will indeed go for option b) and write some nice code. To go 
more into
implementation details (which means Jules is going to find something 
wrong with
it:-), it's going to have a mini type system, where each type has 
metadata about
its fields, and how to convert them to binary format ( it uses a lot of 
the offsetof()
macro), but the actual input-output code is hooked up to whatever 
backend you want.

So the BalsaApplication, for instance, has a large constant structure 
(itemlist) that looks
along the lines of:

{
	STRING_FIELD( BalsaApplication, bcc, "BCC", "" ), 
	/* Member bcc of BalsaApplication, saved with the handle "BCC", 
with an empty default */
	BOOLEAN_FIELD( BalsaApplication, sig_onreply, 
"UseSignatureOnReply", TRUE ),
	/* Member sig_onreply of BalsaApplication, saved with the handle 
"UseSignatureOnReply",
           with a default of TRUE */
}

et cetera. Then there's a function for the 'BalsaApplication' type that 
performs an
operation for each 'child' that it has, *without needing to know what 
the operation is*.

gboolean operation_balsa_app( void *data, operation_t operation )
{
	if( operation_itemlist( data, operation ) )
		return TRUE;
        if( operation_printing_t( &( ((BalsaApp *) data)->PrintingInfo 
), operation ) )
		return TRUE;
	if( operation_address( ((BalsaApp *) data)->address ) )
		return TRUE;
	return FALSE;
}

operation_itemlist goes through the members listed in the aforementioned 
structure and uses
the appropriate basic types (string and number, essentially) to read 
data directly into
balsa_app. 

The basic types are implemented for every operation, and for each 
configuration system. Thus
you have operation_string_gnome_config_read() or 
operation_gboolean_proplist_destroy(). The
latter would be a noop.

There would also have to be abstractions for moving between sections and 
enumerating sections.

Limitations of this system include: 
	- Maps well to gnome-config, but as for proplist and other, it 
remains to be seen.
	- Overkill
	- The itemlist is somewhat hackish, the correct way is to either 
implement everything
	  as an itemlist or implement everything as a function. I believe 
the previous is Correct,
          because my plan was to have as little code like this as 
possible:

	if( read_config_val( "this", &this ) )
		return TRUE;
	if( read_config_val( "that", &that ) )
		return TRUE;
	.... etc for many many lines.

	  However, to do this correctly requires a way to specify which 
section a key is in,
	  which is not always the same (if each mailbox has its own config 
section....)

	- Reading in the configuration has proven to be less than 
beautiful.
	- Defaults are currently bound to the type metadata, so if an 
Address appears in multiple
	  places its defaults will always be the same.

Good features are:
	- We can convert between all configuration formats transparently if 
the backend is written.
	- We can use the same backend with different parameters, for 
instance to provide system-
	  wide defaults and overrides.
	- Once established the system is verrrrry extensible, and a piece 
of cake to expend as
	  well.
	- Much less duplicated code -> less chance for problems.
	- Usable elsewhere, in Balsa and even pretty much able to be ripped 
out and dropped into
	  other programs.

I'll attempt to give updates of my progress.

==============================
Peter Williams peter@newton.cx