Re: [boost] libsigc++ inclusion (was Formal review request: Signals library)

From: Karl Nelson (kenelson_at_[hidden])
Date: 2001-12-26 20:21:51

> 
> I haven't been here very long, but:
> 
> > Could some one please explain to me why a large library which the author
> > has offered to boost at several points continuously is ignored in favor
> > of NIH (not-invented-here)?
> 
> There is much evidence to refute the existance of significant NIH. Not the
> least of which is the fact that nothing was invented here, just about
> everything has come in from somewhere else. As an example, one that has
> caused the most recent noise is the work being done to get parts of Loki
> into boost.

This case seems very NIH (from my horribly biased prospective.)
I have suggested libsigc++ in the past as a boost component, but 
the reasons given for not including it were fairly strong, only 
now it appears those reasons have vanished and a new set of design
arguments have appeared.  Why was it when I first proposed signal/slot
implemention boost didn't need such functionality as it was too blended
with functor, but once function and bind (horrible, horrible name!!)
which others said were all that are needed, does the signal/slot
seems appropraite? 

> > Just for the record (in case no one wants to search the archive), SigC++
> > 1.1 is solely copyrighted by myself.  It is free for all to use 
> > under LGPL and I will automatically revert the license to public domain
> > should it ever by included in the stl standard.
> 
> I could be mistaken but I believe that the simple fact that it is covered by
> LGPL ensures that it will not be considered in upcoming versions of boost,
> much less the standard. This is something you would have to change before
> submitting the library for inclusion.

I don't know.  Has it ever been stated that a library must be some
particular license prior to acceptance?  If I offer it to boost as
something other than LGPL and it is refused, than I have no
means to protect the library from inclusion in say the
next version of .NET or something weird without much credit to me. 
I subscribe to the beliefs of the FSF and as such I am only realy
willing to transfer such a large piece of my work to a "broader standard".
Until then I would perfer people contribute back.  However, I have not
accepted any recent contributions specifically so that I can meet the
boost requirements.  Something clearly stated in the development 
branch.  If boost doesn't want it, it is destined to be signed over the
the FSF, as the only thing which prevents me from doing so is to 
leave open the possiblity of boost inclusion.

Currently, I have the right to protect my library from 
modifications without recontribution.  
I will give up the right only when accepted into a broader standard
(at which time the standard by virtue of distribution makes 
protecting from modifictation irrelevent.) 
Must a file meet the standards for boost before inclusion or
simply after inclusion?

> Based on the amount of discussion that the Signals library generated I am
> surprised that you didn't get a lot of feedback and encouragement when/if
> you offered to boostify it.

It has been offered in the past and refused.  Which is why
I am annoyed now!  I rewrote all of SigC++ based on considerable user
input from a clean slate as earlier attempts were not really up
to the task.  I did it without help from others soly to meet the
desires of boost. 

That said there are significant hurtles to ever including sigc++.
  1) SigC++ uses a totally different naming convention.
     (Part of which I am clearing up tonight because numerious
     users have problems with the current sigc++ convention.)

  2) SigC++ maintains itself with autoconf and similar tools.

  3) SigC++ has some sections which are redundant to reviewed boost 
     components, though they were not necessarily such when sigc++
     was written and proposed. 
  
  4) After inclusion in boost, SigC++ will live on as an LGPL component 
     until such time at it makes the stl standard.  Which
     means contributions to it will not necessarily go back to boost
     if done by someone other than myself.

That said, if boost accepts the current set of functor/bind/signal
combination, and then tries to place it in the stl standard, I
feel they will be doing a bit of a disservice as some of those
elements are handled much more gracefully in sigc++.   Thus at
least if sigc++ isn't included a serious discission of the features
that sigc++ offers and doesn't should be seen here again prior
to accepting any signal/slot library. 

BTW.  If you are going to drop the slot side of the equation, 
you should really drop the signal name.  Signal/Slot is a unified
concept and thus if there is no slot class but functors are used, 
don't use the signal name.  It is so badly overloaded between 
Unix system calls, including a class "signal" would really be asking
for pain in the long run.

--Karl