I do have a quick question for you. Is there a reason for your choice of using std::strings instead of cstrings? My experience with these is that they can often be terribly inefficient, both in memory usage and cycles. You might not see this in BincIMAP since you have short lived processes, but my company has a broad sweeping policy now to no longer use them, because we discovered (through profiling) that a huge amount of time was being spent in these routines. While they do help protect you from buffer overruns, this often comes at an extremely high cost.
If I get the opportunity at some point, I may do a little profiling on the BincIMAP code with various sized Maildirs and see what the results are. (No promises on timeframe though... I've been awfully busy lately.)
Cheers,
bs.
On Sunday, March 23, 2003, at 01:23 PM, Andreas Aardal Hanssen wrote:
Hi, Ben!
On Fri, 21 Mar 2003, Ben Schumacher wrote:Andreas-
When you saw child process, are you fork then exec'ng? Can you not just
use a pipe to communicate back to the parent process and have it deal
with the socket code. I imagine it might be possible to fork and exec
and not use a pipe, but that's one possible solution.
I think the problem is that you need to get all SSL context information
into the child process, which I'm not exactly certain how to do.
I guess the fall-back solution is to pipe the data through the parent, although I was hoping that the child could issue a renegotiation and continue on native mode.
I tried the pipe solution last week and it really looks ugly ;) but if
that's the only way we know, then I'll go for it for now and see if I can
make the piping code weaved into the design.
Andy :-)
Glad to hear BincIMAP is progressing.
Cheers,
bs.
On Friday, March 21, 2003, at 06:51 AM, Andreas Aardal Hanssen wrote:Hi, everyone. Some updates here.
VERSION NUMBERING -----------------
The latest Binc release was 1.0.25-2. I'll be making some changes to version numbering now that I know better what changes are likely to happen are which aren't. :-)
The scheme we'll use is this:
<major>.<minor>.<bugfix>-<dist>
Minor will alter between odd and even numbers. Odd numbers mark unstable development releases. Evens are stable.
major : Complete redesign \_ Different programming language / concept \_ Major license/distribution changes
minor : New major features / enhancements \_ Loadable C++ class modules support \_ Support for new authenticators \_ Privilege seperation, etc..
bugfix : Minor new features and primarily bugfixes
dist : Changes to the way Binc is distributed (spec file changes, documentation updates, etc)
MILESTONE ---------
The 1.0.26 release is turning out to be such a great mile stone that I
will be releasing it as 1.1.0 and not 1.0.26. So 1.0 will be left as a
"stable" branch and we will continue development on 1.1 (unstable),
only
fixing bugs on the 1.0 tree.
When we are confident that 1.1 is ready for production, the project
will
move from beta to production stage 1.2. Core development work will then
continue on 1.3, and so on.
NEW SITE --------
The domain bincimap.org has been registered and will soon take over for
bincimap.andreas.hanssen.name serving the Binc IMAP website at a new
stable location. The .name domain will still point to the server
currently
hosting the site (aka infeline,org), serving as our first mirror.
Anyone
interested in mirroring the site I encourage to contact me (bad
english!!)
;)
NEXT RELEASE ------------
Ok, leaking some stuff about the 1.1.0 release:
- Will support privilege seperation - checkpassword invoked daemon - Loadable module support - Initial contributions: loadable modules that add support for several extensions like IDLE, ID, SORT. These contributions will serve as examples on how easy it is to add extensions as a completely seperate task/project while leaving the Binc IMAP core development untouched.
The 1.1.0 release will be out next week. If anyone can help me with figuring out how a child process can continue SSL communication after the parent did the SSL_accept, then 1.1.0 will probably be out sooner rather than later.
Good weekend everyone!
Andy :-)
