>Sa Jan 31 2009 06:35:48 EST von IGnatius T foo...@uncnsrd >Betreff: Re: Citadel commit log: revision 7045 > >I think that fixes OpenID. There was a problem with the conversion to >strbuf in that code. > > I do like the StrBuf class, but we seem to incur a lot of bugs during >conversion. That being the case, I would like to decide right now that we >should *not* start converting anything in citserver to use StrBuf, because >it's likely to introduce bugs that could corrupt data. We can use StrBuf for >*new* modules in citserver, but let's keep existing code as it is. > > We are probably at a point now where we can start testing the new code on >Uncensored. I'll get to that in a day or two, at a time when I can keep a >close eye on it. >
Yes, its indeed like that. Theres a reason why I didn't start using it in citserver so far. (next to being busy with messing up webcit ;-) Webcit is stateless, and will come back after a crash with less usability impact than citserver. If it has remaining errors, finding them in webcit is the better place. I think the primary place to start using strbuf could be situations where dynacmic buffer lengths ( & reallocating) have to be handled. I also think theres another good reason not to start reworking everything; at least for short usages strbuf replaces one malloc by two; and as we all know libc locks on malloc, which is bad for multithreadded applications. My future plans target on webcit & templating, which actualy mostly is another layer on strbuf... Short term targets are the rooms logic and the sieve editor; longer term are tasks, vcards and calendaring plus DAV access to files. Though having lost several hundret lines by replacing the rumpelstilskin handler lookup by the hashlist handler lookup session_loop is still to monolitic for my taste and another place for change. Maybe wcsession could use some more modularity; plus I'd like to work on static output not being session dependant, so they can be handled in paralel.
