Douglas E. Engert wrote:
The proposal describes multiple merge modules. Assemblies are for libraries. We would have one shared side-by-side assembly for the core libraries and one for the credential cache. Then there would be separate merge modules for the command line tools, the integrated logon support and the credential manager (currently NetIDMgr).Sounds like a good idea. Are you leaning toward the single assembly or the multiple assemblies?
MIT.KerberosV was selected because this assembly is for the krb5 related libraries.You name the assemblies MIT.KerberosV...
Other names would be selected for the other merge modules and assemblies.For those requiring Krb4 support for example the existing libraries could be
packaged into a MIT.KerberosIV assembly.
\MIT\Kerberos is the name which is already in use for the installation and the top-level software registry keys.But for the Common Application Data, you use ...\MIT\Kerberos
Is there some reason for having the V in one but not the other?
One is general and the other is not.
Future versions of OpenAFS and Putty would ship with the KFW merge modules built into their installation packages.You talk about third party applications. OpenAFS and PuTTY are two that come to mind. What would be an upgrade strategy for these?
Yes. In fact it would be required to because the old application would be unable to find the libraries in the shared assembly. An old application could be updated by adding a .manifest file for each module to the same directory that contains the application'sIf some application did not get upgraded, I assume it could still use the current version of KfW.
executables.
The credential cache will be shared as long as the two applications each are using a compatible credential cache format whether that be a compatible ccache server,If an application had its own private copy of a Kerberos assembly, what about the ticket cache? Is it shared, could each have its own?
a compatible file format, or something else. Today on 64-bit Windows 32-bit apps in the WOW64 environment use the 32-bitKFW and the 64-bit apps use the 64-bit KFW. They each have their own ccache server instance. Whichever one gets started first is the one that is used. The other instance sees the first and exits. However, if the ccache server RPC messaging changes (as will happen when CCAPIv2 is replaced by CCAPIv?), then individual ccache servers will be running and the two
applications will no longer be able to share the CCAPI credential cache.
You could install the Debug version of the libraries but the command line tools will not be linked to it. The command line tools are just another set of applications on the machine.Could one install the Debug version of the assembly, but not the Debug version of the command line tools? Or would one just install the debug version.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ kfwdev mailing list kfwdev@mit.edu http://mailman.mit.edu/mailman/listinfo/kfwdev