Re: making "spamassassin" a meta document

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

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


I'm happy with the "sa-check" idea, as long as we keep a "spamassassin"
wrapper that just does an exec().  easy enough, and very sensible.
+1

I think the POD docs from "spamassassin" should be split into the
"sa-check" POD and whatever other "sa-blah" scripts we come up with
from that.

also, +1 on Michael's "sa-history" script idea.

however the cvs/svn style, I'm not fond of.  reasons:

    - without require-ish hacking, it'll mean all the commands
      would get "use"'d -- increasing RAM usage.  I'd prefer to
      avoid that.

    - having multiple commands as "prefix-command", e.g. "sa-learn",
      "sa-check" etc. is good as a UNIX UI -- "sa-<tab>" to get the list
      of possible commands.

    - the POD file for that one wrapper would be gigantic and unusable.
      we could go for an svn-style "spamassassin help", but then we'd have
      to write our own documentation-reading subsystem, which seems like
      wasted effort when POD is already there and already working nicely
      on all platforms.
      
      also, TBH I find that kind of subsystem to be an annoying UI -- do I
      read the man page?  do I type "blah help"?  "blah help commands"?
      etc.

- --j.

Malte S. Stretz writes:
> On Sunday 23 January 2005 00:22 CET Daniel Quinlan wrote:
> > I've been thinking about bug 3635.
> >
> > One idea:
> >
> >    rename "spamassassin" to "sa-check"
> >    make "spamassassin" a meta document that execs sa-check for backwards
> >       compatibility
> >
> > Another idea:
> >
> >    make "spamassassin" a meta document that execs sa-check for backwards
> >       compatibility
> >    move spamassassin pod to "spamassassinrun" document
> 
> Yet another idea:
> 
> make "spamassassin" a caller for all tools, a bit like the cvs commands.  
> Like this:
>   old                  | new                  | calls
> -----------------------+----------------------+----------------
>   spamassassin         | spamassassin check   | sa-check
>   sa-learn             | spamassassin learn   | sa-learn
>   spamassassin -r      | spamassassin report  | sa-report
>   spamassassin -d      | spamassassin clean   | ...
> 
> All sub-commands could be moved to /usr/lib/spamassassin (and out of $PATH 
> when some compatibility flag is disabled) at some point.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFB9dKqMJF5cimLx9ARAnFrAJ4jZADFAFpatVb3Qv43wzPxIdrIiACfUctg
+oUJccV9ZM55PI5MhRJUHfI=
=Yw+C
-----END PGP SIGNATURE-----

Re: making "spamassassin" a meta document

["Malte S. Stretz" <ms...@gmx.net>]

On Tuesday 25 January 2005 06:01 CET Justin Mason wrote:
> I'm happy with the "sa-check" idea, as long as we keep a "spamassassin"
> wrapper that just does an exec().  easy enough, and very sensible.
> +1

Yeah. +1

> I think the POD docs from "spamassassin" should be split into the
> "sa-check" POD and whatever other "sa-blah" scripts we come up with
> from that.
>
> also, +1 on Michael's "sa-history" script idea.

And what about sa-report (instead of -r) and sa-clean (or whatever for -d)?

> however the cvs/svn style, I'm not fond of.  reasons:
>
>     - without require-ish hacking, it'll mean all the commands
>       would get "use"'d -- increasing RAM usage.  I'd prefer to
>       avoid that.

Umm... no, not at all:
  exec("sa-" . $ARGV[0]);

>     - having multiple commands as "prefix-command", e.g. "sa-learn",
>       "sa-check" etc. is good as a UNIX UI -- "sa-<tab>" to get the list
>       of possible commands.

Yeah, good point, I use bash-completion :)  

>     - the POD file for that one wrapper would be gigantic and unusable.
>       we could go for an svn-style "spamassassin help", but then we'd
> have to write our own documentation-reading subsystem, which seems like
> wasted effort when POD is already there and already working nicely on all
> platforms.

I would create a very small POD which just refers to sa-{learn,history,...}

>       also, TBH I find that kind of subsystem to be an annoying UI -- do
> I read the man page?  do I type "blah help"?  "blah help commands"? etc.

I just remember the old RCS mess where you had all those commands in your 
$PATH and always thought the CVS solution was a good one.  Whatever, sa-* 
isn't bad either, maybe we could combine those two ideas.  Or not do the 
master-fork-app-thingy at all *shrugs*

The latter would just have two advantages:  For one, less code duplication.  
Currently we have some code to set the lib path and do the param parsing 
both in spamassassin and sa-learn.  If we create more scripts we also have 
to maintain that code at different locations.  The second is less docu 
duplication.  We have to document the common commands like -D in all apps.


Hmmm... the latter could be avoided if all apps become libs, like 
CmdLearn.pm once was but at some namespace and directory which would make 
it clear that they aren't part of the public API, like
  tools/lib/Mail/SpamAssassin/bin/learn.pm
then we could create the caller scripts on build time or even use symlinks 
which decide based on their name (just playing with the idea, it probably 
has some flaws).

This apps-as-libs solution could solve another thing:
$ wc {.,spamd}/*.raw
  1130   5283  37074 ./sa-learn.raw
   847   3753  29179 ./spamassassin.raw
  2544  11077  81337 spamd/spamd.raw
  4521  20113 147590 total
$ wc lib/Mail/SpamAssassin{/*,}.pm | tail -n 1
 23323  85827 668441 total
Wouldn't it be nice if those masses of code in the apps themselves 
(especially spamd) could be split into a bit more managable pieces?

Cheers,
Malte

-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>