Hi Chris, On Fri, Dec 4, 2009 at 10:13 AM, Chris Denham <[email protected]> wrote: > Hi Robert, > Yes, looks possible to use the AuthenticationMap, but it doesn't seem > appropriate in this context. The username and httpAuthentication type would > be ignored as the zip decompressor only needs a password. > Wouldn't users find this more confusing than just supplying the password? > Also, I wondered if I had missed something as it looks to me as though the > AuthenticationMap method is still an 'Options' based solution? > I can change it if you feel strongly that it should be changed, but from what > I can see, unless we also refactor AuthenticationDetails, it seems simpler to > use the method I used. > If we were to refactor AuthenticationDetails perhaps it could become an > abstract base class for HttpAuthenticationDetails and > ZipAuthenticationDetails?
I would rather have a standard scheme for providing passwords to plugins, the AuthenticationMap's original stimulus for development was http hence the bias in the design. I'm open to suggestions on how to make it a little more general purpose. In terms of a ZipAuthenticationDetails class perhaps name it a little more generic such as PasswordAutherticationDetails. I also wonder about having a ReadResult that passes back information from plugins that require username and/or passwords so that one could allow apps to bring up a dialog box and ask the users for authentication details and then passes this to the plugin. One could possible use a callback for doing this, but I'd be inclined to think that this will be less flexible as the constrain the app to implement what they want from within the plugin, but perhaps a callback could be used in conjunction with the ReadResult values to allow users to implement it either way. Thoughts? Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
