Justin Mason <[EMAIL PROTECTED]> writes: > I agree with Daniel that we should model the command line UI around the > use cases, not around the code subsystems involved.
yay! ;-) > But then "plugin-specific stuff like bayes" -- Daniel, I'm not sure > what you mean here, this seems to contradict the previous idea (UI > based on use-cases). I mean that *if* there's some aspect that can't be generalized, then it should go into a plugin-specific front-end. I think there are few, if any, cases of that, though. For example, --backup and --restore could become standard plugin APIs and the format could be extended to handle more than just Bayes. > On another aspect --- I like Michael's idea of leaving the > "spamassassin" script's UI intact as it is now for a few 3.x > releases. There is a lot of third-party code that hooks into > SpamAssassin that will need to be updated before that interface can be > removed safely without causing a lot of needless pain. Well, it might be cleaner to junk the "sa-filter" idea and leave "sa-filter" as a 100% clean future program. Move the code back into "spamassassin", but document it under the meta document or in a separate pod. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/
