Scribe Test4 Directions
Date: 2/6/2006
Apart from fixing the new Scribe crashes that are appearing in Test2 and Test3 I just wanted to say a few words on where I'm heading in Test4 in terms of upgraded functions and features.

  1. Fix Bug #42 by implementing a new search function using the Filter UI that I wrote last year.
  2. Improve the mail2 export with all the feedback I'm getting. So far the dialog wording is ambiguous and some defaults need fixing. Also some things in the backend need to be reworked a little and support for other types of objects needs to be added.
  3. For many many versions Scribe has supported the one folder format, and older versions read/write the mail2 file without issues. But I want to make some non-backward compatible changes to the file format. I want to move the body of messages into child nodes of messages instead of being a property of the message node itself. And then maybe force all the messages to be in a single data block so that I can read them in without seeking around inside the mail2 file. This would be the ultimate fix for folder loading speed. But it would not be backward compatible, so I'd have to call it "mail3". At the same time I'm also thinking of supporting maildir + indexes as a mail store. Which would likely involve API changes, which combined with the mail3 changes would make sense to do at the same time.
  4. I would also like to rip out the crusty MIME parser that Scribe's been using for like ever now and replace it with the shiny new one that doesn't suck. The issue with that is a lot of the "smarts" with charsets and decoding of content is embedded in the current MIME parser and needs to be extracted out so that it can be added to the new parser. Which is a) painful and b) likely to be buggy to start with.

Here is where the rubber hits the road. If the software is going to get "better" then it needs to get worse in the short term as I rip out badly written code and insert better foundations. Change always brings unstability in the short term. It's a constant in the software industry. Especially with a dev team of one. The options are lots of fast turn around test builds that are not stable, or no releases for a while (months?) and then a relitively stable release. What would you, as a user prefer?
02/06/2006 3:20pm
I like the sound of the first option best. Lots of buggy test builds gives all us users to get an idea of what is happening with the program and give feedback. Just so long as there is a clear distinction between the buggy releases and the stable I don't think it'll be a problem.

Also, I think there needs to be some sort of utility that can convert the mail3 strore down to a mail2 store. Just in case people accidentally grab the newest version of the program, start using it and then realize that they'd be better off with the more stable version.

Just my $0.02.
03/06/2006 11:25am
i second that first bit.

as for the conversion, the export and import functions + available communication options should solve those situations.
On the other hand, it's probably not that difficult to make

04/06/2006 8:44am
I also vote for the first option. It's nicer to participate in the development this way - interactive progress :-)

Besides, I'm confident (based on the experiences until now) that all changes will work rather nicely, so I'd keep a backup of the previous version (and mail2file) but would not hesitate to use the new system.

Email (optional): (Will be HTML encoded to evade harvesting)
Remember username and/or email in a cookie.
Notify me of new posts in this thread via email.