Aaron Stone wrote: > > are supposed to work as per RFC 3501 (exactly like 1:* and 12:335, > > respectively). But they won't. > [snip] > > Should I, perhaps, file a bug in Mantis? While this RFC option is > > unlikely to be used in real life, it's still in the RFC, so this is a > > bug. > > Yes, please do file bugs for things like this, and include the patch as an > attachment
My patch does not fix the larger:smaller number compliance. I don't have a fix for this, and thus will probably file a bug. I'm afraid I won't be able to file bugs for my existing patches; got some pressing matters, sorry. Besides, 3 of 4 patches don't fix any bugs, but rather speed things up. (Actually they're partial fixes for what I'd consider design bugs, but this is a different matter). The sole fixed bug is well known and may already be in Mantis. > Thanks for all of your help Mikhail, you've been a powerhouse of fixes in > the past two weeks. I look forward to your future projects with DBMail! These projects will be, for now, of a "develop and document storage and ideas" nature. I've hit a personal barrier regarding C coding; I just can't spend too much time learning all those C tricks for what Python does automatically. However, I *am* interested in the storage part. DbMail for me is not only a local storage engine (this works, more or less, after those fixes). It's a first implementation of an important concept - database email storage. So I'd really like to reach an agreement on the storage table layout (frr the 2.1 and upper series), and then to document it clearly - I can do that as I'm a tech writer. Then different implementations could access the same database. My ultimate "dream" idea - definitely not for today or tomorrow - would be a database-oriented mail reading program. With SQL as the native storage format, it could do wonders with views and such stuff. But I'd prefer to have an established table layout (and a working server for things like receiving mail) before even aproaching this. (The reader itself, if I am to do any coding, will be in Python; but database-level interoperation won't care about languages). Yours, Mikhail Ramendik
