Improvement to unreleased open_session change?

[ximon18]

Regarding the Replace SessionFlags with bool to open session unreleased change I have a concern.

With the new code one ends up with a call like:

ctx.open_session(slot, true)?;

The reader is left wondering what does that true do so I modified my code like so:

const READ_WRITE: bool = true;
let session_handle = ctx.open_session(slot, READ_WRITE)?

However, this issue wouldn't exist if instead an enum were passed in rather than a bool.

Calling @vkkoskie as the original author of the change and who is thus perhaps best placed to comment on it.

[ionut-arm]

Hmm, I don't particularly like the bool, but an enum just for this seems like overkill. What would you think if I just removed the parameter and introduced another method, open_read_write_session (or open_rw_session...)?

[ximon18]

I'm fine with either suggestion as they are both more obvious than the current bool. As "rw" is used by the PKCS#11 standard itself as an abbreviation I would be fine with that (e.g. ulMaxRwSessionCount and CKS_RW_PUBLIC_SESSION).

[vkkoskie]

Oh, hi there! I guess you could say I've mostly moved on from contributing here. The work I was doing that motivated my contributions was OBE, and the general frustration with Oasis' silence about licensing stalling #66 was a little more than I was interested in dealing with for what was intended to be a fun side project.

I think this change is mostly orthogonal to my earlier changes. Those were to remove an argument that didn't really make sense. The bool was the closest match for a replacement type for what was left. But it wasn't an opinionated choice.

I'd say among the proposed choices I prefer two functions.

Without advocating one way or another for it, I'll also mention that some APIs will opt for a marker type here. A good example of this pattern is openssl's PKey struct which is generic over empty Private and Public types. A private key can do anything a public key can but the reverse isn't true. Likewise here with RW sessions being able to do anything a RO session can. Just something to consider.

[ximon18]

Thanks @vkkoskie, that's a sad story, and very useful interesting API design feedback, thanks!

[ionut-arm]

The generic approach sounds good, but beyond my bandwidth right now :( I can do the "two functions" for now and change it to a generic-based solution for a later release when I get some free time, or I can let someone else take this over?

[ximon18]

That someone wouldn't be me as I don't have the bandwidth to take this on at the moment.

[ionut-arm]

Apologies for the delay. I've implemented the "two methods" approach in #101 , will look at maybe implementing the generics approach after I get up to speed following the summer lull.

Let me know if that approach seems sensible to you.