[Libssh] Enhancements proposals

[Rodolphe Rocca]

On Wed, 27 Feb 2008 23:56:59 +0100
Aris Adamantiadis <aris at 0xbadc0de.be> wrote:

> Hello,

Nice to see you back Aris :-)

> > 
> > 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 ?

Yes. It could be possible to say : 

- ok encrypt this data and let me send it as I want
- hey I've received some data on a socket, decrypt that

To be honest, I've not thought intensively on the subject, especially on
how a developer would handle the first exchanges with a server during
the connection, I don't even know if it's possible, but it would be a
very interesting use case for the library. 

> 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.

You could achieve that in C. Think about something like cairo which is a
very good C library with a backend concept.

> > 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.

Yes, my comment is valid only if freeing SSH_SESSION* is up to the
developer.

More generally what I have in mind is a consistent and systematic
OO API :

ssh_session_new
ssh_session_free
ssh_channel_new
ssh_channel_free
ssh_options_new
ssh_options_free

etc.