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 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list