<<< Date Index >>>     <<< Thread Index >>>

Re: mutt development and road map



Hi,

* Paul Walker [05-07-15 01:05:37 +0100] wrote:

Trying to design something like you suggest for the UI and mailbox drivers
would be hard, would require a large amount of effort, and probably wouldn't
work very well for quite some time (if at all). Working to milestones etc.
isn't particularly fun, so you won't get many people doing it. And, IMO, the
payoffs aren't nearly enough to be worth it. Okay, so you can add new mail
types, or plug a new UI in. So what? Who's really ever actually going to do
this?

It's not about to ease adding new stuff but removing old code. For example, if some day hopefully mbox dies, the patch to muttng will be a single line and a removal of two source files but not more because in order to remove a module, you only need to kick it's registration if the design was done well. For example, I don't really use mbox anymore but am forced to build mutt with support for it. I don't see any reason to do so. By having modules you can kill mostly all the ifdefs in the code (because it uses the high-level generic internal API) and make only module registration/compilation handled by ifdef. Many applications suck because they introduce lots of bloat and so does mutt. But there's no need to.

The target audience for text mode mailers is tiny anyway compared to GUI
mailers; time spent on a fully modular mutt is time not spent making the
existing mutt work better.

But the point is that making it work better takes lots of time because of some missing internal abstraction. Doing a redesign also has the consequence that in the future can be trivially made suck even less because changing something is easy due the good design.

 bye, Rocco
--
:wq!