[Libssh] Enhancements proposals

[Aris Adamantiadis]

Hello,

Rodolphe Rocca a écrit :
> Hello,
> 
> I've been using libssh quite intensively and I have to say that it works 
> quite well, especially since release 0.2.
Thank you, it's that kind of mails that makes me feel I have to go on on 
improving libssh.
> 
> However I have a few concerns that I would like to see improved in this 
> library.
> 
> 1) It uses too many namespaces. OK, there is no namespace concept in C, 
> but ideally function names should all start with the same prefix (ssh_ 
> or libssh_).
I just verified. I agree with your remark. I had prefixed the options() 
functions but not the channel and string ones. I don't remember if I had 
reasons not to do. Maybe backward compatibility or number of lines 
having to be manualy edited to correct it (C code refactoring sucks).
I probably won't correct it, because as I state in the other mail, 
libssh is going to be rewritten in C++.
I still need feedback about how the C layer should be 
(backward-compatible or a fully-featured C++ layer ?)
> 
> 2) Encryption and transport layers should be independent :
> ideally it should be possible to use the encryption layer without having 
> to use the transport layer, or at least libssh should provide some 
> transport hooks (send/recv function pointers) that developers may use to 
> set their own transport functions instead of the ones provided by libssh.
> 
I don't understand the point of the first part of the sentence. Does it 
mean you'd like to use the encryption layer without sending packets off 
the net ?
The second part is what i've had in mind when initing the C++ port : 
have a good plug-in design which makes using libssh over some kind of 
transport easy.
> 3) ssh_disconnect should not delete the SSH_SESSION : it mixes memory 
> management with a connection management which is bad. It just makes 
> memory management hard for developers. ssh_disconnect should only free 
> SSH_SESSION local data that cannot be reused (like encryption data), but 
> options especially should remain attached to the SSH_SESSION, in such a 
> way that it should be possible to chain ssh_disconnect and ssh_connect 
> on the same SSH_SESSION.
> 
You're completely right, it's probably one of the first 300 codes lines 
that had been written that I never refactored. Definitively WILLFIX, but 
I have to find ways of fixing this without breaking legacy code.

> 4) I would to see ssh_cleanup renamed to ssh_free but it's just comsmetics
It's right. Even though this is not a public function.
> 
> Please tell what you think about that.

I'll definitively take care of your remarks in the design of the next 
release. Thank you for bringing them in light.

Regards,
Aris