Re: svn commit: r153377 - in spamassassin/trunk: MANIFEST Makefile.PL build/do spamassassin spamassassin.pod

[Justin Mason <jm...@jmason.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Daniel Quinlan writes:
> Michael Parker <pa...@pobox.com> writes:
> 
> > Now you're adding in a whole other subsystem.  Using this logic, it is
> > pretty easy to argue that everything should be in one executable, and
> > not split out.  A little cross use is allowed.  Here is my proposed
> > set of commands and their arguments:
> 
> > [...usages removed...]
> > sa-filter
> > sa-report
> > sa-learn (maybe sa-bayes)
> > sa-update
> > sa-history/sa-awl (maybe sa-whitelist)
> > sa-lint
> 
> Hmmm... my thinking is that we have several basic actions people
> perform.
> 
>  - filtering and removal of markup
>  - learning/forgetting
>  - reporting/revoking
>  - plugin-specific stuff that cannot be generalized
> 
> I'd strongly favor move the basic learn functionality (learn, forget)
> into a single command regardless of the learning subsystem and the
> plugin-specific stuff like bayes, whitelist, and history into
> plugin-specific commands.

I agree with Daniel that we should model the command line UI around the
use cases, not around the code subsystems involved.

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).  

Regarding the idea of splitting plugin-specific stuff into its own
command-line UI, I'm not sure I can go for that.  For one thing, having
two command-line APIs to control Bayes seems confusing; for another, the
plugins should hook into the *existing* user interface, not create new,
plugin-specific UIs that'll only work with that plugin.  If we do the
latter, we'll wind up down the road with multiple, conflicting scripts
that are nearly the same in UI, but not quite, for each different plugin
of a given type.


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.

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFCG3MiMJF5cimLx9ARAo9SAKCjP2+ePv4nC7Zj9v7v+g0UcMkiRACdFL+Z
NpfYw6kTNCyUIldvM5Giq2A=
=rnNj
-----END PGP SIGNATURE-----

Re: svn commit: r153377 - in spamassassin/trunk: MANIFEST Makefile.PL build/do spamassassin spamassassin.pod

[Michael Parker <pa...@pobox.com>]

On Tue, Feb 22, 2005 at 11:44:37AM -0800, Daniel Quinlan wrote:
> Justin Mason <jm...@jmason.org> writes:
> 
> > I agree with Daniel that we should model the command line UI around the
> > use cases, not around the code subsystems involved.
> 
> yay!  ;-)
> 

BTW, I don't think we're on different pages here. Or maybe I'm missing
something.  But I agree with just about everything y'all said.

I do think we're in for a world of hurt if we remove things from the
'spamassassin' script for 3.1, we need to officially deprecate the
interface and warn on usage, maybe deprecate and wait til 3.1.1 to
warn.

Michael

Re: svn commit: r153377 - in spamassassin/trunk: MANIFEST Makefile.PL build/do spamassassin spamassassin.pod

[Daniel Quinlan <qu...@pathname.com>]

Justin Mason <jm...@jmason.org> 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/