RE: [NeoStats-Devel] ADNS and libevent

> Justin Hammond wrote:
> > Some *other* people were using our implementation of adns 
> > with libevent... I added that so they could update the fd 
> > callback  for them... 
> 
> And I am supposed to know this how? 
> 
> I did announce my intentions prior to making the changes. The 
> project is
> NeoStats, not library repository for libevent so I assume 
> that anything
> within the NeoStats source tree can be modified for NeoStats 
> use. If you
> wish to provide a library repsitory for libevent or for any 
> other prupose,
> why not create a separate project for these "other" people to 
> rely on that
> will never be affected by NeoStats specific changes? This 
> would have the
> additional advantage of allowing it to be properly packaged 
> as a standalone
> download.
> 

And as mentioned before, I've had hardware problems, hence my lack of work
in the last week. I've had intermitant access to the internet, and honestly,
I've been concentrating on paying customers when I have been down. 

I guess as previously mentioned on this list with regards to the whole
library debates, I'm a proponent of the GPL in effect of "giving back" to
the community. Although the development might not be active on the library,
its still actively supported by the authors
(http://www.chiark.greenend.org.uk/pipermail/adns-discuss/2005/001094.html
as a example) so at any time, there might be updates to it. Last year there
was discussions about adding ipv6 support to ADNS. It never materialized
into anything yet, but if someone were to write it, we now have *more* work
in updating our ADNS to support ipv6 if we ever need/want to support ipv6 in
NeoStats..... 

The last thing I want to do now is go out and start maintaining separate
copies of libraries as a separate projects. It would just overall detract
from what time I have from NeoStats... At least when it was as a library in
the NeoStats project, it was still fairly portable, in that they could just
take the adns library directory and use it in another application. Now we
have tied it to be NeoStats Specific and any work I do on maintaining a
separate copy would have no benefit to NeoStats. 

Agreed that the project is NeoStats, but I'm honestly scratching my head as
to the benefit of porting ADNS to use our abstraction layer? I don't believe
we had any porting issues with ADNS on either Win32 or *nix platforms (we
did have two libraries... But your initial merge of these two libraries
sorted that out without having to use our abstraction/memory management
functions correct?)

Maybe its just more from the point of view that I see this as fixing
something that wasn't broken.... :) My original change to ADNS was pretty
minimal, and if you didn't use libevent or some other io abstraction, it had
no effect on you... Now we might as well not call it ADNS anymore.