Is the runtime configuration seeping too deeply?

I just committed r25167, which (among other things) adds apr_hash_t *config
parameters to two WC functions (svn_wc_get_switch_editor3(),
svn_wc_get_update_editor3()). I did this because:

   a) those functions needed a value that is stored in the runtime
      configuration, and
   b) it was just as easy to pass the whole configuration
      as to pass the one needed item, and
   c) there was precedent for this with svn_wc_get_status_editor*.

In retrospect, though, this makes for an awkward API. Why should callers
need to generate a whole configuration structure just to pass a string value
to these functions?

I think I should change my code to do just that (and plan to do so). But
here's my real question -- should we also change svn_wc_get_status_editor3()
too, *removing* the 'config' parameter and adding the one 'default_ignores'
parameter it actually needs? svn_wc_get_default_ignores(), which takes a
'config' hash, too, is the likely reason the status function takes a
'config' -- it just gets passed thru to svn_wc_get_default_ignores().

I can't put my finger on the exact reason, but the runtime configuration
area *feels* to me like something that only libsvn_client and individual
client programs should even know about -- that the WC, RA, and server-side
APIs should be ignorant of it, and take their instructions from their
callers directly. (And yes, this means that svn_wc_get_ignores() and
svn_wc_get_default_ignores() would need to be changed, too.)

Thoughts?

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand