On Tue, Dec 04, 2007 at 12:57:39PM +0000, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
> virConnectPtr virConnectOpenAuth (const char *name,
> virConnectAuthPtr auth,
> int flags);
I'm a fan of callers passing in the size of the structure (as they see
it). Allows the structure to be expanded in future, and if done right
can allow both forwards and backwards compatibility.
So we never came to any conclusion on this...
- Pass sizeof(*auth) in as a param
- Have allocator/destroy functions for the auth param
- Use the flags field to indicate use/presence of extra auth members
IMHO, this whole discussion is rather over the top. The 'auth' param is
merely a convenience to hold the data related to the auth callback, ie
what credentials the auth callback support, the callback function pointer
and the opaque data. There aren't going to be any params added to this
struct, because the list of the params to the auth callback function itself
is fixed. Adding an allocator / sizeof doesn't magically let us change
the callback function signature.
NB, there are lots of extra args & data that an application will want to
pass in when opening a connection, and we may well be adding more of
these in the future. We already have a place where we pass these in - the
URI string. This is used to choose authentication mechansim for example.
Any data required by authentication mechansims is fetched asynchronously
via the calllback.
So we already have 3 places to future proof ourselves - the URI string,
and the set of credentials that can be fetched via the callback, and
the 'flags' param of which we only use 1 bit. Adding sizeof or allocators
to give a 4th way to future proof is frankly overkill and uneccessary
complication.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules:
http://search.cpan.org/~danberr/ -=|
|=- Projects:
http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|