On Nov 26, 2009, at 1:27 AM, Peter Stuge wrote:
>> In any case, if I can get a final opinion from the group on this,
>> I'm happy to implement it.
>
> Let's figure it out first. Please be patient and comment a lot on all
> the good and bad ideas.
Sounds fair enough.
> The thought that occured to me before was that we might need to take
> a bit of a stand in libssh2 here on whether it should provide error
> codes that are close to the protocol errors (which I would prefer) or
> whether it should try to be smart and cook protocol error codes into
> something that could be expected that application writers would
> prefer, or just where we think that protocol errors suck.
>
> Personally I rather like the protocol but on the other hand maybe
> it's too low level sometimes?
Maybe we can break this discussion into two chunks:
1) Since this is a bug in a key part of libssh2 (i.e. authentication!)
-- should the current patch be applied for now?
2) Improving libssh2 in order to have "richer" error reporting
I'd advocate for doing #1 to fix the bug while discussing #2 which I think is
probably more of a long-term project. In any case, let me have a go at getting
the ball rolling for #2:
We could obviously add a bunch more error codes that map on to more of the
underlying errors, although in doing this, we will no doubt cause some problems
for application developers. First, we could break existing behavior; an
application expecting LIBSSH2_ERROR_PUBLICKEY_UNVERIFIED might now get some new
error code indicating a more specific [protocol-level] failure code. Secondly,
there are already 40 or so error codes, do we really want to add yet more for
an application developer to worry about?
Maybe a better approach is to break down the errors into high level groups or
"classes of error" that have more of a tangible meaning at the application
level, for example:
* Authentication Errors
* Transport Errors
* Protocol Errors
If we had a way of encoding this information into the error codes -- for
example rather than simply assigning sequential negative integers, we could put
an error "group" in the high word, for example:
#define LIBSSH2_ERROR_AUTHORIZATION_FAILED
-((LIBSSH2_ERRORGROUP_AUTHORIZATION << 16) | 0x01)
#define LIBSSH2_ERROR_PUBLICKEY_UNVERIFIED
-((LIBSSH2_ERRORGROUP_AUTHORIZATION << 16) | 0x02)
...
With this approach, any existing application can be recompiled and will work
as-is without any additional code changes. But if I want to have my
application detect authorization failures so that I can retry them (for
example, when logging in) rather than simply giving up with "Internal libssh2
Error", I can now check the error group and perhaps retry the login for an
authorization failure.
Another option would be to simply leave the error handling as-is, but introduce
a new API function that allows more detailed "sub error" information to be
retrieved; for example by adding a new libssh2_session_last_error_ex() API.
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
