Douglas E. Engert wrote:

Sounds like a good idea.

Are you leaning toward the single assembly or the multiple assemblies?
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).

You name the assemblies MIT.KerberosV...
MIT.KerberosV was selected because this assembly is for the krb5 related libraries.
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.
But for the Common Application Data, you use ...\MIT\Kerberos
\MIT\Kerberos is the name which is already in use for the installation and the top-level software registry keys.
Is there some reason for having the V in one but not the other?
One is general and the other is not.

You talk about third party applications. OpenAFS and PuTTY are two that
come to mind. What would be an upgrade strategy for these?
Future versions of OpenAFS and Putty would ship with the KFW merge modules built into their installation packages.

If some application did not get upgraded, I assume it could still use
the current version of KfW.
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's
executables.

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?
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,
a compatible file format, or something else.

Today on 64-bit Windows 32-bit apps in the WOW64 environment use the 32-bit
KFW 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.

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.
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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
kfwdev mailing list
kfwdev@mit.edu
http://mailman.mit.edu/mailman/listinfo/kfwdev

Reply via email to