Another reason I went with the approach I took is that
it is more flexible (for example, it allows you to
pre-populate the db with anything you wanted...).
It gives any crypto implementation a chance to run
some start/stop scripts.
Well, I don't see problems with start/stop script. Again, the logic is: if config is not NULL and NSS DB exist: open it if config is not NULL and there is no NSS DB: create it if config is NULL: init NSS w/o DB If anyone already has an NSS DB then there is no problem at all.
Probably you can't eliminate the list based store until you have symetric keysThe generic keysstore interface defines the keystorefindmethod to return a "xmlsecKeyPtr". In other words, the method is returning xmlsec objects and not just crypto objects. The xmlsec object contain a lot more info than just the crypto handles. So NSS db can't replace the keystore completely. I'm using the NSS db as an alternative source of keys (sort of a "read-through" cache).
I was thinking about speeding up lookups in the simple
keysstore, but it is not easy to replace the list with
a hashtable because many different criteria are used
to lookup a key, and may not all be defined (name, type,
usage, etc..).
from NSS DB. After that there should be no problem. You just re-create xmlSecKey
object from NSS DB key handle every time you need it.
Aleksey
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
