Re: [hylafax-users] Generating a Caller-ID only log file

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Aidan Van Dyk wrote:

> * Lee Howard <faxguy@xxxxxxxxxxxxxxxx> [060314 11:40]:
>  
>
> But using your qualifycid-ex, you can't do that type of
> screening based on device either (except for running different
> qualifycid-ex scripts for each device).
>  

Nah, just like DynamicConfig the first argument to QualifyCID-Ex is the 
device name.

> Sure - you need a different file,  But how bad is:
> $SPOOL/etc/cid.accept:
> 	.
> $SPOOL/etc/cid.reject:
> 	!.
>
> And then it's another line that your DynamicConfig has to output.
> 	QualifyCID: etc/cid.reject
> or 
> 	QualifyCID: etc/cid.accept
>  

Sure it's easy for us... but I'm just not sure how obvious that will be 
for a newbie to conceive.

Furthermore, by doing it this way we essentially obsolete the old 
QualifyCID approach - this new approach being far more versatile, and we 
may as well abandon the old method, I think, if this is the case.

> You see - the point is that if DynamicConfig is changing QualifyCID, it
> *knows* if the call is going to be answered or now. 
>  

If DynamicConfig were always controlling QualifyCID then this would be 
true, otherwise not.

> I actually was working off the assumption that dynamic config was being
> run on *all* incoming calls - that it wasn't being run on calls being
> reject was on oversite on my part - something that I probably would have
> suggested fixing before.   Until I saw that setting QualifyCID had no
> effect on the current call (only on the next call)...
>
> And I think running DynamicConfig *before* the call is "answered" is
> actually the correct thing to do.  For instance, it should be able to
> change any configuration, one of them being the qualifycid that is used.
>  

There are other config items that DynamicConfig cannot control.  For 
example, the CallID stuff, RingsBeforeAnswer, probably others.

I'm certainly not opposed to making DynamicConfig more versatile, 
however, by moving it ahead of isCIDok, but in doing that I believe that 
we should make DynamicConfig responsible for whether the call will be 
answered or not so that it can act accordingly - and remove any 
possibility of any uncontrolled QualifyCID setting from interfering there.

> I think taking exit status of DynamiConfig would be a better solution
> than a separate script invocation.

I'm fine with this, too.

> But what about adding a "ANSWER:
> REJECT|ACCEPT" line that it prints generates. That single line could easily
> control the result of answering/rejecting, etc without needing a
> backwards-incompatible change.

I'm fine with this, too.

> We could even only check that if
> QualifyCID is not set if we're concerned about complete backwards
> compatibility.
>
> But, for the 4.2 series, I don't see backwards compatibility as a big
> thing.  Unfortunately, we've played loose, and broken bigger things in
> pushing features in..
>  

HylaFAX development has been far more concerned, over the years, with 
backwards compatibility than most other development projects that I know 
of.  To me it's a good thing to have if it's easy to do, but otherwise, 
just move on and don't let that ambition create future confusion and 
problems.  For something like this keeping backwards compatibility 
doesn't matter at all to me... but, like I said before, I wasn't really 
wanting to make that decision independently.  But, take your pick of 
whatever of these options that I agree with, and let me know where to go 
with this.

Thanks,

Lee.


____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*