[
https://issues.apache.org/jira/browse/PROTON-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530120#comment-13530120
]
Ken Giusti commented on PROTON-181:
-----------------------------------
Strictly speaking of the proton-c implementation: the restore database is
stored in the domain object. So restoring a session to a different domain is
not supported.
Point to consider - even if it were supported (imagine session persistence),
wouldn't the domain configurations have to be identical in order for the
session state to be valid enough to permit resume?
> SSL layer - deprecate old per-connection credentials API, introduce new
> top-level configuration domain
> ------------------------------------------------------------------------------------------------------
>
> Key: PROTON-181
> URL: https://issues.apache.org/jira/browse/PROTON-181
> Project: Qpid Proton
> Issue Type: Wish
> Components: proton-c, proton-j
> Affects Versions: 0.2
> Reporter: Ken Giusti
> Assignee: Ken Giusti
> Fix For: 0.3
>
>
> In the first two releases of the SSL layer, the model only provided a
> per-connection object (pn_ssl_t). Thus, all configuration had to be applied
> each time an SSL connection was created.
> As new capabilities were added to SSL, this model has proven to be
> inadequate.
> With session resume, a new top-level object was introduced: pn_ssl_domain_t.
> This object becomes a "factory" for pn_ssl_t connections. Common
> configuration, such as credentials and CA database, are configured at the
> pn_ssl_domain_t level, and are adopted by each connection (pn_ssl_t) that is
> created.
> This model not only reduces the configuration actions need by the app, but
> results in a cleaner SSL implementation since the underlying SSL libraries
> (OpenSSL and Java's SSL) use a very similar model.
> More detail of the new api can be seen in PROTON-136.
> The problem now become support of the old api. Behavior becomes a bit vague
> if we allow credential, etc, configuration on both the domain and the ssl
> connection. Given the brief exposure of the existing api, we'd like to drop
> support for the following existing SSL API methods:
> pn_ssl() - constructor
> pn_ssl_init()
> pn_ssl_set_credentials()
> pn_ssl_set_trusted_ca_db()
> The corresponding functionality would instead be available via the
> domain-based api.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
