[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