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