[jira] [Resolved] (PROTON-733) SASL related updates (wishes)

["Andrew Stitcher (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PROTON-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Stitcher resolved PROTON-733.
------------------------------------
       Resolution: Not A Problem
    Fix Version/s: 0.9

The reporter seems to say that this is no longer a problem.

> SASL related updates (wishes)
> -----------------------------
>
>                 Key: PROTON-733
>                 URL: https://issues.apache.org/jira/browse/PROTON-733
>             Project: Qpid Proton
>          Issue Type: Wish
>          Components: proton-c
>    Affects Versions: 0.8
>            Reporter: German Shepherd (PrE)
>            Priority: Minor
>             Fix For: 0.9
>
>
> Let me add a another set of SASL-related 'wishes':
> I'm running ProtonC on a memory constrained environment.
> After the SSL is connected, then there is a SASL PLAIN auth taking place.
> After the SASL is done doing its thing, it is basically not required any more
> (not until the whole connection is dropped and then reopened - this is my case).
> So after the dispatch of
> {{0 <- sasl-outcome(68) [ code=0, additional-data=b"Welcome!" ]}}
> I would like to have the SASL to release all its dynamic memory (the whole object) and remove itself from {{transport->io_layers[ PN_IO_SASL ];}} (replace SASL I/O functions with a pass-through functions).
> This way, there is a very welcome drop of use of the dynamic memory, as the actual test of this approach shows.
> As a another wish, I would like to get a new global flag (or better yet, a pn_xxx callback function) added, which the application can query, to see when the SASL is done - this is somehow crucial for timing of the behavior of the user application in a memory constrained environment (e.g. do not proceed with message memory allocations until the connection and SASL is actually done).
> Perhaps a better approach might be possible here (so far this particular way worked well), I'm all ears.
> I understand that none of the both request do apply for the 'normal' use of the ProtonC (where dynamic memory is not the limitation), but yet I would like to have the option, even if delimited with a {{#ifdef}} configuration.
> The amount of work to do this is minimal, yet I would like to get this discussed and done the official way,
> so I won't need to manually update the ProtonC code after downloading it.
> thx



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)