[kmf-discuss] Opinions wanted - new init/create APIs

[Massimiliano Pala]

Hi,

Actually the whole parameters handling is quite strange to me.
I usually tend to program C as I would in C++, therefore I want
to provide wrapping functions to set the fields in the data
structures.
This really helps when changing the data structures is needed
as applications should use the provided functionalities instead
of directly accessing the data fields.

I know it adds a quite large number of functions to the API,
but I guess this is worth the effort on 99.99% of the cases :D
You might consider this, so that in the future changes in the
API would impact less on the apps.

For the moment I just have a couple of internal functions I use
to alloc/free the memory of data structures so that I am sure
they are correctly zeroized.

Summarizing, I think that wrapping functions for *_PARAM would
solve your problem better than the PKCS#11 approach because, in this
way, you have more control on the type of data that is passed as
parameters.
Internally you can then have the attribute/value pair conversion
and a general function that will pass the parameters to lower
levels of the kmf stack. Anyway, this implies more coding :(

Cheers,
Max

Wyllys Ingersoll wrote:
> Regarding all of these new interfaces...  We've had some internal
> conversations for a while about what to do with the
> current KMF APIs.   We are a little uncomfortable with the
> current APIs because any time we need to change to the
> parameters (the *_PARAM) structures), it changes the
> ABI and has a pretty significant impact on the library and
> all of it's consumers.
> 
> We are considering moving to a model similar to the PKCS#11
> API where the functions all accept an array of attribute/value pair
> records.  This would allow us to change the required input
> parameters for any given function without actually changing
> its prototype signature or the overall ABI of the library.
> 
> Of course, we would like to make the change so that the
> current APIs remain available, but would phase them out
> eventually.
> 
> So, I'm not sure yet that we will go forward with the
> new Alloc/Init functions until we determine how we are
> going to proceed with the rest of the API.
> 
> -Wyllys
> 
> 


-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            pala at cs.dartmouth.edu
                                                  project.manager at openca.org

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3088 bytes
Desc: S/MIME Cryptographic Signature
Url : http://oss-beta1.opensolaris.org/pipermail/kmf-discuss/attachments/20070319/83588ac9/attachment.bin