[NeoStats-Devel] Status

"Justin Hammond" <justin-kLev/[email protected]>
Newsgroups gmane.comp.neostats.devel
Message-ID <[email protected]>
Hi all,
Just wanted to drop a email and see what the status with NeoStats was. As
you probably seen, I've been working on the perl interface the last week or
so, and now most of the "learning curv" with regards to perl is complete,
its just a matter of duplicating the C API for bots into a Perl API. 

Once this perl API is complete, my only other urgent requirement is to make
perl scripts callable from modules (For SecureServ dat file stuff), and
fixing up the update.c code so that I can get duplex communications running.

I know that previously I have talked about other "changes" to NeoStats
(Database support etc) but now I figure that its time to move with getting
3.0 out the door as a full release, and work on these new changes as a 3.1
release instead.

So, I'd like to hear your comments. My major plans for 3.0 core are left at:
1) Perl Modules, and Perl Support in SecureServ (I need this for updated
defintions that require some logic with regards to signatures)
2) update.c (or report.c or whatever.c) codes to be done. Actually the
backend of this is already complete, but I need to work on portablity and
stablity issues with regards to this. See MQServer in the repository for a
project that's been partially funded by one of my customers at Dynamx... 

For my thoughts about things outside 3.0 core, I think can all be approached
as modules, so there should be no dependancies on us making any futher
significant changes to existing API. They are:
1) a version module, to basically just do a HTTP request to see if you have
the latest module
2) a channel linking module (dependant on update.c above) 
3) A webserver module (prompted by a discussion with DNB tonight.... Very
early thoughts though)

So Mark, Seeing as 3.0 core is being lead by you is there anything else you
want to see in 3.0 (apart from obvious bugfixes or Win32 interface
tidyups!!! (see following emails)).

I guess I'm thinking for core 3.0, its overdue to move to another alpha, and
then feature freeze mode and only fix bugs for 3.0 release. Lets get 3.0
final out the door, and put 3.0 into maintence mode (with bugfixes or
features that do not modify existing API's) and start thinking about 3.1

Finally, I know for 3.0 I have been a bottle neck, and made some bad calls.
I apologize for this, but honestly, what I have done with regards to socket
code or perl API are things that I felt were critical (Socket code from
point of view of performace, and Perl API from perspective we needed better
logic in SecureServ dat files). (confuse/SQL support is something I still
want to look into, but now I realise it's a case of "why fix something
that's not broken", so it can wait till 3.1)

As far as modules, well, these can be independent of any 3.0 release, so no
problems there. The only thing I would like to see (any volunteers?!) is a
new webpage/website for the "external" modules. And of course, I'd like to
start disucussions about proper documentation for not only the core, but
also the modules.

Mark, One thing I was wondering about (I installed Visual Studio finally) is
that if you can put together a "programing guideline" for NeoStats? Not just
covering things like module API, but also the abstraction interface you put
in. (eg, ns_malloc, versus os_malloc, versus malloc?!?! That still confuses
me) 


So thoughts? I honestly have a priority to get the Perl API done ASAP
(hopefully within the next 2 weeks) and update.c I'll discuss seperatly, but
should not hold back the next alpha release if we time this right. 

Cheers

Justin
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.