[hylafax-devel] Re: config/usr-xon & usr-rts

[Dmitry Bely <dbely@mail.ru>]

Darren Nickerson <darren@dazza.org> writes:

Darren, you have obviously missed the point here. We discussed the
following (*not* *adaptive* *answer*):

config/usr-xon:

ModemSetupAACmd:	AT+FCLASS=0	# leave modem idling in class 0
ModemAnswerCmd:		AT+FCLASS=1A	# answer in Class 1

config/usr-rts:

ModemSetupAACmd:	AT+FCLASS=0&H1&I0&R2	# leave modem in class 0
ModemAnswerCmd:		AT+FCLASS=1&H1&I0&R2A	# force RTS/CTS after change

Please reread your text again and explain me what are you going to do with these
lines (and also their purpose)?

Comment them the following way:

#
# Very valuable parameters, but why original author introduced them, is not 
# known to anybody.
#
# ModemSetupAACmd:	AT+FCLASS=0	# leave modem idling in class 0
# ModemAnswerCmd:		AT+FCLASS=1A	# answer in Class 1
#

Or what?

>   +> I'm suggesting that just because we don't understand why the original
>   +> author made those paticular config entries, is no reason to remove them.
> 
>   Dmitry> ... if the original author really worked around some firmware bugs
>   Dmitry> and had enough skills/experience to do that right :-) This is not the
>   Dmitry> case here (as well as in many other config templates).
> 
> 
> You have not met the burden of proof on that one yet . . . at least I don't 
> think you can say the person who wrote the lines in question was lacking 
> skill/experience.
> 
>   +> It may be apropriate to comment them out if they are no longer
>   +> needed on current models.
> 
>   Dmitry> Basing on all my programming experiece, I don't agree completely. All
>   Dmitry> non-obvious code, not commented well, should be removed/rewritten as 
> soon
>   Dmitry> as possible. Support of such code costs much more than writing 
> properly
>   Dmitry> designed new one, believe me :-)
> 
> 
> If it's clearly wrong, it should go. We're nowhere near that point though, 
> have you demonstrated that it is incorrect and I have somehow missed that? If 
> so, sorry. Otherwise we should decide on a policy of either enabling it when 
> supported, or adding the right enabling code but commenting it in default 
> installs. By all means let's tidy up the commenting, but I don't think 
> deleting it is warranted based on the discussion I've read to date. Alas, we 
> don't have the resources to re-write all non-obvious code in HylaFAX (that 
> would be most of it), but a little more commenting would certainly be 
> appropriate.
> 
> 
>   +> What I am trying to avoid is removing altogether entries from the
>   +> config files that MAY still be necessary for some older models.
> 
>   Dmitry> ... only if it is clear why they are/were necessary.
> 
>   Dmitry> If somebody claims that 2*2=5, but does not explain why, also just
>   Dmitry> leave it there in hope that it's really so with some older CPUs?
>   Dmitry> :-)))
> 
> 
> Of course not. Have you shown us that the lines are wrong? I don't think you 
> have. I think you may have shown us what the spec recommends, but I don't 
> remember seeing what the modem actually does, and a demonstration that the 
> current default config is as wrong as 2*2=5.
> 
> 
>   +> If they are left in as comments then the knowledge is not lost.
> 
>   Dmitry> There is no *knowledge* is such comments, just a frustration for the
>   Dmitry> reader, because nobody will understand why it's commented out.
> 
> 
> HUH? Surely if the line were to be commented out there would also be a
> 2-liner comment inserted to explain why that is the default?? So I don't
> see why the user would be frustrated!? Right there, without them even
> having asked, is all the config options they need to enable to get AA to
> work on their modem, along with a few lines explaining that fact. Bonus!

Hope to hear from you soon,
Dmitry




____________________ HylaFAX(tm) Developers Mailing List ____________________
 To unsub: mail -s unsubscribe hylafax-devel-request@hylafax.org < /dev/null