I'm in the middle of rewriting the client-side authentication system,
and people are right: it's much simpler and cleaner to have "RA pull
info from client when challenged", rather than "client preemptively
push data at RA". Many problems drop away, and code gets smaller.

I have one design problem, though.

Here's a typical code flow:

1. client calls

session_baton = RA->open (URL, vtable_of_callbacks)

2. client calls

RA->do_some_network_things (session_baton)

* the RA layer is challenged by Apache

* the RA layer uses the callback vtable to get information from
the client. (the client has its own logic for getting info
from argv[], or files, or user-prompts.)

Here's the missing feature: if authentication was successful, it's
very likely that the auth info needs to be stored somewhere on the
client. (IOW, cached for next time. We're already doing this in our
current auth system.)

How does the client know if info needs to be stored? Or which info
needs to be stored?

- One possibility is that each RA->do_something() call return this
information.

- Another possibility is that RA->close() is the only call to return
this information.

- Another idea is to have RA do the auth storage itself, via another
vtable callback. Each RA routine would have to remember to do this
before returning.