Improvement to unreleased open_session change? about rust-cryptoki HOT 7 OPEN

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.

from rust-cryptoki.

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

from rust-cryptoki.

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

from rust-cryptoki.

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

from rust-cryptoki.

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?

from rust-cryptoki.

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

from rust-cryptoki.

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.

from rust-cryptoki.