Stream errors vs. SASL errors

[Brett Zamir]

I see that if we were to treat SASL errors as belonging to a 'connector'
event of state 'error', we'd have a namespace conflict, as the local
name for a SASL error "not-authorized" is also the same as a stream
error local name... Maybe a new state "failure" would be appropriate? (a
TLS failure might piggyback on this state, but with no child elements
present). I really think it would be ideal to avoid the ugliness of
namespaces both for typing and friendliness to new users. The only
stream-level elements which I can see expanding beyond the specification
are stream features and SASL mechanisms, and I think these should have
their own events and/or processing, so as to avoid namespace conflicts.

Btw, in the process of handling SASL errors more specifically, the
current handling for the connector error "auth" should probably be moved
into an implementation file's listener (which makes sense also for
moving the one string that needed localization out of the service files).

Brett

[Massimiliano Mirra]

On Tue, Sep 16, 2008 at 3:59 AM, Brett Zamir <bre...@gmail.com> wrote:
>
> I see that if we were to treat SASL errors as belonging to a 'connector'
> event of state 'error', we'd have a namespace conflict, as the local
> name for a SASL error "not-authorized" is also the same as a stream
> error local name...

But we are surfacing the whole error element from the connector, not
just the local name, aren't we?

Or do you mean the conflict happens when the caller uses
getStreamErrorMessage()/getStreamErrorCondition()?