On Mon, Dec 03, 2007 at 04:13:53PM -0500, Daniel Veillard wrote:
On Thu, Nov 29, 2007 at 05:19:31PM +0000, Daniel P. Berrange wrote:
> When the callback is invoked, it will be passed a list of virConnectCredentialPtr
> structs which contain details on all the credentials that the authentication
> mechanism needs to collect. They are passed all at once to make it easy to
> construct a big form in UI:
>
> typedef int (*virConnectAuthCallbackPtr)(virConnectCredentialPtr cred,
> unsigned int ncred,
> void *cbdata);
okay, I have just two remarks about the API: that the callback seems to
get passed an array of virConnectCredential as first argument, not a
list of virConnectCredentialPtr.
Yes, I'll fix the comment to reflect this.
Also I hope we won't end up with
too many
virConnectOpenAuth flags, maybe using a long to be sure we can fit at least
64 options might be a good safe thing to do. We have not been very consistent
so far in libvirt for the flags, sometime using int/unsigned int/unsigned long
maybe unsigned long is safer and cleaner, i could see how various
authentications options may end up growing that set over time.
I don't anticipate the flags will be widely used in the future. Aside from the
callbacks, and the read-only flag, all interesting params are part of the URI
string. We already have a 32-bit 'int flags' param in the remote protocol wire
format for the open call prior to this patch, so we can't make this new API
use 64-bits without changing wire ABI. I'm not really worried though - I
rather doubt we'll ever use this flags params for much.
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 -=|