[Libssh] Enhancements proposals

[Aris Adamantiadis]

Rodolphe Rocca a écrit :
> Aris Adamantiadis wrote:
>> Rodolphe Rocca a écrit :
>>> On Wed, 27 Feb 2008 23:38:02 +0100
>>> Aris Adamantiadis <aris at 0xbadc0de.be> wrote:
>>>
>>> Are you sure you want to switch to a C++ version ? I mean, libssh has
>>>  already a good OO design in C, it is not so far from a _very good_
>>> OO design. Furthermore, there is the classical argument in favor of C :
>>> everything can link to it. Personnally I don't see a very strong reason
>>> for a protocol library to use C++.
>> The ease of development ? Doing a good OO design is C is nearly 
>> impossible. There is no inheritence, no virtual methods,... 
> 
> Off course I wasn't talking about strict OO but more of using OO 
> notation as in the linux kernel or many C libraries (cairo, gnutls are 
> very good examples of this). A big part of libssh already uses 00 
> notation, I was just talking about making libssh use OO notation everywhere.
> 
> However I understand that C++ allows for much cleaner design than C.
> 
>> look at the 
>> mess in error.c to support inheritence (ssh_set_error that works on two 
>> datastructure) and the mess in crypt.c to support virual methods.
> 
> Are you talking about multiple #ifdef ? I agree it's not the cleanest 
> thing ever. However libssh could probably integrate a much cleaner 
> crypto backend framework along with a libcrypto and libgcrypt backends.
> 
Not really, i'm talking about the C structure, the function pointers in 
it, the functions that try to mimic virtual methods and inheritence.
>> C and C++ are completely compatible : it's easy to build a C stub which 
>> runs the C++ methods behind.
> 
> Well I know that C is compatible with C++, but not C++ with C, unless by 
> using very complex technics. So I'm very curious how you would do your 
> stub in such a way that any native C library could compile and link 
> against it.
Just compile with g++ a code like
extern "C" {
  struct my_c_struct {
     myClass *c;
  };
  int C_function_do_this(struct my_c_struct *this, int arg){
    return this->c->do_this(arg);
  }
}

it works, I've tested it.
> 
> And even if it's possible, you'll still have to design your C API...
that's right. It will follow the external C++ api. But it's much less 
hasle than having to design the whole code with these tricks.
> 
> Notice that I don't have any personal interest in keeping C for libssh : 
> my application is written in C++. However I'm seriously thinking about 
> the wide amount of applications written in C that could not use libssh.
> 
or the applications that won't want to use libssh because it's C++ and 
c++ is the root of all evil. Bad for them.
The only industry that will prefer the C version for good reasons is the 
embedded industry. I think they can use the 0.2* versions because they 
won't need the 0.3 features.

>>>> Thus, I think a good action I have to make to repair my lack of 
>>>> attention is to install a correct bug manager (I think about mantis). 
>>>> That way, every bug report and feature request would be kept
>>>> somewhere. Also, I promise working a day or two this week to address
>>>> some of the known bugs and include the patches.
>>> It would be very very good for us if you could setup a git repository
>>> somewhere for source control. And it would be good for you too making
>>> really easy to merge patches and developpers branches.
>>>
>>> NB : For those who don't know git is a distributed source management
>>> software used by the Linux kernel, and many of the big free software
>>> projects. 
>> I already have a SVN repository on berlios. I don't know what features 
>> of git lacks in subversion
> 
> OK I didn't know you already had a SVN repository. It's already a good 
> choice.
> 
> The main difference between git and svn is that svn is centralized while 
> git is distributed. In brief every developer _locally_ owns a complete 
> copy of the repository. It has many advantages among those :
> 
> - the ability to work on different branches locally
> - the ability to do local checkins
> - it is really fast (all operations are local)
> - and many others
> 
> So every developer works on its own copy of the main repository and when 
> a developer branch is ready people send you a patch, or better tell you 
> to merge the branch in your main repository.
> 
> It is very well adapted to free software development.
> 
> If you want to know more I can recommend to try the tutorial on the git 
> web page it's quite informative.
I'll read it when i get some time.

Regards,
Aris