Feature #596
closedZrusit polozky timeout a priority
0%
Description
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.
Updated by Jan Soukal almost 12 years ago
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.
Updated by Jan Soukal almost 12 years ago
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?
Updated by Pavel Kácha almost 12 years ago
- 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.
Updated by Jan Soukal almost 12 years ago
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.
"Hlidatko" duplicitniho reportovani jsem odebral, takze ted budeme spamovat 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).
Upravil jsem to nakonec tak, ze ma errMsg pouze jeden novy parametr - type. Bud err (jako chybova hlaska) nebo warn (jako warning). Verbose se cte z konfiguraku a v pripade $type == 'warn' se nebere v potaz.
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.
Souhlas.
Updated by Pavel Kácha over 11 years ago
Ok, pokud jsi dobře otestoval a považuješ za hotové, nastav "resolved".