apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: current dbd initiatives
Date Thu, 08 Jun 2006 08:20:15 GMT
On Thursday 08 June 2006 08:04, Bojan Smojver wrote:
> Quoting Chris Darroch <chrisd@pearsoncmg.com>:
> > 3) Error reporting via a standard set of APR_DBD_* error codes
>
> Switching to APR_DBD_* error codes will *probably* break binary
> compatibility requirements for 1.x (i.e. int will become apr_status_t,
> which is probably the same thing, but I'm not sure if we're allowed to
> assume that). So, this would most likely be a 2.0 thing. Some long
> term APR folks may have more input on this...
>
> >    Overall, this seems like a *large* effort to me.  Forewarned is
> > forearmed, I guess.
>
> Yes, this is a can of worms of gigantic proportions. We'd need to
> define a set of error codes that map into *all* underlying error
> conditions and then return that consistently. Although it's The Right
> Thing To Do (TM) and we *should* do it, I'm personally not pressed to
> go that way in a hurry - I can live with the current 0/not-zero
> situation for a while (read: too lazy to do all that work right now ;-).

Agreed.

The underlying issue here is one that's not limited to DBD, though DBD
is the most-affected area of APR.  What's needed is a general review of
the use of apr_status, including more flexibility about introducing new
status codes.

> > 5) Renaming functions like apr_dbd_get_entry() to apr_dbd_entry_get().
> > Is this the kind of thing that can be done with a minor version number
> > change, i.e., in 1.3?
>
> I think Garrett already answered this one - only possible when jumping
> major versions. So, this is something for 2.0.

It seems to me that the current practice is perfectly consistent with other
parts of apr_util.  Let's just review the apr-util headers for all modules 
containing functions names having a noun and a verb in:

In the apr_module_noun_verb camp:
	apr_buckets
	apr_ldap_init
	apr_optional
	apr_optional_hook
	apr_reslist
	apr_rmm

In the apr_module_verb_noun camp:
	apr_base64
	apr_date
	apr_dbd
	apr_dbm
	apr_hook
	apr_ldap_option
	apr_md4
	apr_md5
	apr_queue
	apr_sha1
	apr_uri
	apr_xlate

In both camps:
	apr_ldap_url
	apr_memcache
	apr_xml

So, it seems that apr_dbd is simply following the majority practice
in its naming convention.

-- 
Nick Kew

Mime
View raw message