Warden

Soubezne s vyse uvedenym u odesilajicich klientu testovat, zda klient zadava nejake "ne-implicitni" hodnoty do poli timeout a/nebo priority. Pokud ano, upozornit uzivatele warningem (na stderr, do Syslogu), ze tato pole budou do budoucna (v. 3.0) zrusena - ze jsou obsolete.

Zmeny provedeny v branchi warden-client-2.2 v revizi 1b487ec4

Zrusit polozky timeout a priority v dokumentaci. Resp. oznacit jako "obsolete". V API zustanou tyto polozky zatim (min. do verze 3) zachovany kvuli zpetne kompatibilite.

V README je nyni uvedeno, ze polozky priority a timeout jsou nyni povazovane za zastarale (obsolete) a od verze 3.0 budou zruseny i v API.

Soubezne s vyse uvedenym u odesilajicich klientu testovat, zda klient zadava nejake "ne-implicitni" hodnoty do poli timeout a/nebo priority. Pokud ano, upozornit uzivatele warningem (na stderr, do Syslogu), ze tato pole budou do budoucna (v. 3.0) zrusena - ze jsou obsolete.

• Pridal jsem do WardenClientCommon funkci warnMsg, ktera odesila varovani na STDERR a/nebo Syslog - podle nastaveni v confu.
• Ve WardenClientSend.pm jsem doplnil test na "neimplicitni" hodnoty ve zminovanych atributech. Je-li takova hodnota nalezena, reportuje se varovani.
• Navic jsem pridal do WardenClientConf.pm hash %report_obsolete nesouci booleovskou informaci, zda jiz bylo varovani u danych polozek reportovano, abychom v ramci jednoho cyklu spusteni odesilace nereportovali tutez hlasku tolikrat, kolikrat klient odesle na server.

• bude dobre ukazkove sendery (example-sender.pl.txt) 2.2 a dalsi publikovat jiz s "novymi" hodnotami pro timeout a priority - tedy nejlepe undef, undef.
• zustava otazka, zda nejak resit ruseni atributu i na strane prijimacu?

• ad %report_obsolete - to mi připadá jako zbytečné, když bude hlášek málo, nikdo si jich nevšimne, a kdo si to včas neupraví, zaslouží si mít spamované logy.
• v žádném případě bych to ale neřešil druhou funkcí, která se liší v jednom stringu a odebraném verbose statementu. Spíše bych přidal errMsg volitelné parametry 'prio' a 'verbose' s defaulty 'err' a 1 (tj. pokud nejsou při volání uvedeny, tj. ve většině současného kódu - který bude tím pádem beze změny).
• u přijímačů nebudeme řešit, až atribut nepošle server, budou holt klienti dostávat undef - jinak to zpětně kompatibilně jde těžko, vzhledem k tomu, že se zpráva předává jako list.

Sjednotil jsem volani warningu a erroru (revize 4ceb1a82).

ad %report_obsolete - to mi připadá jako zbytečné, když bude hlášek málo, nikdo si jich nevšimne, a kdo si to včas neupraví, zaslouží si mít spamované logy.

v žádném případě bych to ale neřešil druhou funkcí, která se liší v jednom stringu a odebraném verbose statementu.
Spíše bych přidal errMsg volitelné parametry 'prio’ a 'verbose’ s defaulty 'err’ a 1 (tj. pokud nejsou při volání uvedeny,
tj. ve většině současného kódu - který bude tím pádem beze změny).

    u přijímačů nebudeme řešit, až atribut nepošle server, budou holt klienti dostávat undef - jinak to zpětně kompatibilně jde těžko, vzhledem k tomu, že se zpráva předává jako list.

Ok, pokud jsi dobře otestoval a považuješ za hotové, nastav "resolved".