This patch slightly changes the format of the destcontrols file (with
the thought that this could grow into a jobcontrol file, or such,
possibly with a backwards compatible destcontrols parser ). The file
format is:
[dest=<dest regex>] [owner=<owner_regex>] [client=<client_regex>] action=...

I have a few concerns with the format of this file. I don't really like
the "overloading" of both input fields and output fields with the =
sign. A possible format could be a white-space separated file:
<dest_regex> <owner_regex> <client_regex> <action1> [ [<action2] ... ]
but this doesn't lead to a very extendable format, and makes adding (or
removing) fields problematic.

Thoughts, comments?

DestControls, like QualifyCID, is awkward to begin with, and I'm almost
of an opinion that it would be better abandoned than extended.

We seem to really like the DynamicConfig approach, and I think that it
would be a very sexy feature to replace DestControls with a JobControls
that worked more like DynamicConfig; supply JobControls with an array of
data from sendq (perhaps like we do in FaxNotify), and then let us read
JobControls script output to adjust job properties just like we do
(kind-of) with DynamicConfig.

Then not only do we have a fully extendable job-control mechanism that
is able to use any sendq item, but it can use any other of a myriad of
things (like looking into a SQL database, for example, for someone that
wants to keep all of the configurable HylaFAX data in such a way) to
accomplish the same task. Not only would we have a
better-than-DestControls feature, but we have a darn useful hook to boot.