krb5_cc_gen_new

[Nicolas Williams]

On Tue, Jan 04, 2005 at 01:38:15AM -0500, Jeffrey Altman wrote:
> Nicolas Williams wrote:
> 
> >Ok, let me try a different approach: what will become of the hint, will
> >it appear in the ccache backend (file, MLSA, MEMORY, CCAPI, ...)
> >immediately?  Can it be set via a separate function?  Why no hint in
> >krb5_cc_resolve() (krb5_cc_resolve() can be used to create ccaches too)?
> 
> First of all, we are not changing existing interfaces so asking why a
> hint does not exist in some other function is really out of scope.

I asked because I didn't understand the significance of the hint to
creating unique ccache vs. creating ccaches with specific names.  I
hoped the answer would make it clear -- it did.  See below.

> However, since you mention krb5_cc_resolv(), you don't need a hint there
> because the residual portion of the cache name is generated by the 
> application.  The application decides what the name will be when 
> creating a new ccache.

Ok, so the hint will be used in FILE ccache file name generation?
Right, that was the case in Love's original example.

This answers my question w.r.t. krb5_cc_resolve().

Of course, the hint won't be of much use unless there's an API to
enumerate the available ccaches (like readdir(), I suppose :)

> Providing the hint to krb5_cc_new() allows an application that currently
> needs to query the list of existing caches and generate its own unique 
> name to provide the basis for the name it wants to use and then let the
> underlying library handle the uniqueness.

Yes, I get it now.  But what about ccache enumeration?

> >The hint may actually be useful in some contexts, but not in others --
> >you propose that it be optional, after all.  So why not make it so it
> >can be set via a separate function?
> 
> Using a separate function only makes sense if there is some persistent 
> state that is worth setting that will be used for multiple calls.  The
> use I have for the hint does not require this.

Yes, forget that suggestion.