Mark P11KitIter interface stable

[ueno]

Currently the P11KitIter interface is only exposed when P11_KIT_FUTURE_UNSTABLE_API is defined. Since the interface has been there for many years, it might make sense to declare it to be stable.

A couple of things to consider before doing so:

• P11_KIT_ITER_WITHOUT_OBJECTS was added as a compatibility measure in 3d54011, as P11KitIter previously only supported enumerating objects. Maybe we could make it no-op
• There is a recent behavior change (not part of any release yet) regarding the timing to stop iteration when P11_KIT_ITER_WITH_TOKENS is specified; previously we stopped before opening a session, now we stop after that. If we consider this is an ABI break, we might want to bump SONAME

[ZoltanFridrich]

P11_KIT_ITER_WITHOUT_OBJECTS was added as a compatibility measure in 3d54011, as P11KitIter previously only supported enumerating objects. Maybe we could make it no-op

Why would we make it no-op? I thought that when I specify something like WITH_TOKENS it will enumerate both objects and tokens. What if I dont want to enumerate the objects but only the tokens? Unless I imagined this behavior and actually it works differently.

There is a recent behavior change (not part of any release yet) regarding the timing to stop iteration when P11_KIT_ITER_WITH_TOKENS is specified; previously we stopped before opening a session, now we stop after that. If we consider this is an ABI break, we might want to bump SONAME

Is it an ABI break though? The session is opened automatically now but that shouldnt break anything. I believe that anyone who uses such iterator and manually opens the session, their program should still work.

[ueno]

Why would we make it no-op? I thought that when I specify something like WITH_TOKENS it will enumerate both objects and tokens. What if I dont want to enumerate the objects but only the tokens? Unless I imagined this behavior and actually it works differently.

If we don't care about backward compatibility, we could have WITH_OBJECTS instead of WITHOUT_OBJECTS, which would be more intuitive.

Is it an ABI break though? The session is opened automatically now but that shouldnt break anything. I believe that anyone who uses such iterator and manually opens the session, their program should still work.

What if an existing program is written in a way it manually opens a session when stopped at a token and it doesn't support parallel sessions (i.e., CKR_SESSION_PARALLEL_NOT_SUPPORTED will be returned).

[ZoltanFridrich]

If we don't care about backward compatibility, we could have WITH_OBJECTS instead of WITHOUT_OBJECTS, which would be more intuitive.

But WITH_OBJECTS is the default behavior. I see nothing wrong having WITHOUT_OBJECTS. And introducing WITH_OBJECTS would definitely break majority of code using p11_iter. If we would like to do this (which I dont see the reason to) I could do it in a 0.26.0 maybe.

What if an existing program is written in a way it manually opens a session when stopped at a token and it doesn't support parallel sessions (i.e., CKR_SESSION_PARALLEL_NOT_SUPPORTED will be returned).

Alright, it breaks the ABI then.

[ueno]

Well, I'm talking about using this opportunity (i.e., removing P11_KIT_FUTURE_UNSTABLE_API guard) to introduce backward incompatible changes. Currently it's user's responsibility to define the macro to access the unstable API. Once we remove P11_KIT_FUTURE_UNSTABLE_API it would become our responsibility to maintain the compatibility.

[ueno]

So my suggestion here is like this: for 0.25.1, include a compatibility measure (like #590); in the future, when we bump the SONAME, remove it and WITHOUT_OBJECTS altogether.