Hi,I want to suggest some things that would make the whole connector monster easier to handle (at least at experienced while moving the Smartcard API).
1) Return of a hash containing all leaves under one node.It is very often the case, that you expect a set of config values at a node. Retrieving them requires a loop construct each time on the programmers side. Besides, at least in most cases, the Connector has access to the hash which will make the access a lot faster then first exporting the keys and then getting them one by one.
2) Return of an array of values instead keys, when the node is an ordered list
Same problem as above.3) Fixed naming convention and supporting method for the "multiple resolver problem". In Smartcard Personalisation there are mulitple places that require the following:
* have a list of alternative "resolvers" (Proxy-Connectors) * walk them in a defined order * stop looping as soon as a resolver returns a result * store the id of the used resolver to reuse it in the next request4) Invention of a generic "primary key attribute" to support get/set operations: When I fetch a value from an arbitrary connector and need to update the value later on, it would add extra robustness when we use the primary key of the backend (there might also be cases where it is impossible without a pkey). As the kind and name of the primary key differs between the backend implementations, it should be a generic mechanism (string representation in a known attribute name, suggestion: pkey)
Basically, there are two different ways to make this working:1) Invent new method names to represent the different return types (or pass as parameter) and try to handle an "illegal" request with an exception. 2) Rely on the assumption that the programmer knows what he is asking for and choose the return value based on what we find on the data side.
I would go for 2, and as an addition, I would vote for a new method "meta" that returns meta-information on a node, so if a connector path should really be used with different "personalities", the code can check the node and behave accordingly.
One more issue, unrelated to the above: We need to find a way to handle exceptions in the Connector. Suggestion (very rough): Let the connector "die" on problems, add a wrapper around "get/set" in OXI:Config and transform it into an OXI:Exception.
Oli -- Protect your environment - close windows and adopt a penguin! PGP-Key: 3B2C 8095 A7DF 8BB5 2CFF 8168 CAB7 B0DD 3985 1721
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
