Warden

Je k tomuhle nějaký vážný důvod? V prakticky poslední verzi rozbít kompatibilitu?

Rad bych balik serveru i klienta distribuoval jako jednu knihovnu. Tuto zmenu bych zaznamenal do souboru README a UPDATE a upozornil na ni take nase "zakazniky". Nemyslim si, ze by ta zmena byla az zas tak velka, jedna se pouze o mensi zmenu volani funkce. Priklad volani bude i v ukazkovych skriptech. Pokud s tim ale nesouhlasite, tak staci rict a delat se to nemusi.

No, já myslím, že u serveru to není problém. U klienta jsme ale drželi ve dvojkové řadě celou dobu kompatibilitu, někteří používají 2.0 klienta a nemuseli nic měnit.
Já osobně, pokud bych měl pocit, že je to sloučení potřebné, udělal bych to tak, že bych kód sloučil, ale nechal vedle poloprázdné "stub" knihovny s původními názvy WardenClientSend.pm a WardenClientReceive.pm, které by do svého namespace jenom naimportovaly z WardenClient.pm to, co v nich lidé používají (a byly by v nich velké tlusté komentáře, že nejsou potřeba a stačí použít WardenClient.pm, totéž v dokumentaci). Noví klienti by je nepotřebovali (a mohli by se spokojit s jednosouborovou klientskou knihovnou), staří by nemuseli nic měnit. Ale v okamžiku, kdy se chystáme dvojkovou řadu uzavřít, si nejsem jist, že je taková akce obecně potřeba...

Pavel Kácha wrote:

No, já myslím, že u serveru to není problém. U klienta jsme ale drželi ve dvojkové řadě celou dobu kompatibilitu, někteří používají 2.0 klienta a nemuseli nic měnit.

To nebudou muset ani ted. Kdo bude bude chtit pouzivat starsi klienty (2.0 a 2.1) ten muze bez jakekoliv zmeny, kdo si nainstaluje primo 2.2, tak ten bude uz rovnou vyuzivat nove API, takze zmena volani se dotkne pouze tech, kteri budou prechazet z 2.1 na 2.2 (jen pro informaci, aktualne do Wardenu posila data celkem 9 klientu).

Já osobně, pokud bych měl pocit, že je to sloučení potřebné, udělal bych to tak, že bych kód sloučil, ale nechal vedle poloprázdné "stub" knihovny s původními názvy WardenClientSend.pm a WardenClientReceive.pm, které by do svého namespace jenom naimportovaly z WardenClient.pm to, co v nich lidé používají (a byly by v nich velké tlusté komentáře, že nejsou potřeba a stačí použít WardenClient.pm, totéž v dokumentaci). Noví klienti by je nepotřebovali (a mohli by se spokojit s jednosouborovou klientskou knihovnou), staří by nemuseli nic měnit. Ale v okamžiku, kdy se chystáme dvojkovou řadu uzavřít, si nejsem jist, že je taková akce obecně potřeba...

Podle meho nazoru je toto slouceni potrebne i prave diky tomu, ze se jedna o posledni verzi. Rad bych, aby posledni verze, na ktere se urcite nejakou dobu pojede, byla co nejjednodussi, dodelana a dobre zpracovana. Toto sjednoceni, ktere jsem jiz provedl, nam pomuze v dost vecech (kod se zbytecne nekopiruje, vsechny funkce jsou pekne pohromade v jedne uzivatelske knihovne a konfigurak se cte pouze jednou pro vsechny funkce v ni obsazene). Pri upravach jsem do modulu WardenClient.pm presunul i fuknci getClientInfo, jelikoz jeji drivejsi umisteni v WardenCommon.pm nebylo uplne nejlepsi. V modulu WardenClient.pm jsou tedy nyni na jednom miste dostupne vsechny potrebne funkce saveNewEvents, getNewEvents a getClientInfo.

Navic jsem pri pracech na zabaleni balicku klienta narazil jeste na jednu upravu volani API. Jelikoz ted uz knihovna WardenClient.pm vyuziva promennou __FILE__, neni pri jejim volani nutne zadavat cestu. Volani API se tedy zmeni nasledujicim zpusobem:

- nacteni knihovny drive:

require $warden_path . '/lib/WardenClientSend.pm';

nyni:

require $warden_path . '/lib/WardenClient.pm';

- volani funce API drive:

WardenClientSend::saveNewEvent($warden_path, \@event);

nyni:

WardenClient::saveNewEvent(\@event);

Zajisteni kompatibility pomoci "stub" knihoven pro klienty premigrovane z 2.1 na 2.2 je mozne timto zpusobem realizovat, nicmene pri tomto poctu klientu si myslim, ze vse lze v pohode zvladnout poznamkou v dokumentaci a jednim mailem do skupiny napriklad s prilozenym one-linerem pro zmenu stavajicich uzivatelskych klientu.

user#115 wrote:

Zajisteni kompatibility pomoci "stub" knihoven pro klienty premigrovane z 2.1 na 2.2 je mozne timto zpusobem realizovat, nicmene pri tomto poctu klientu si myslim, ze vse lze v pohode zvladnout poznamkou v dokumentaci a jednim mailem do skupiny napriklad s prilozenym one-linerem pro zmenu stavajicich uzivatelskych klientu.

Obávám se, že dokumentaci nikdo nečte, zvláště ne při upgradu, kdy si díky našemu dosavadnímu tvrdému přístupu ke kompatibilitě zvykl, že nemusí. Dva poloprázdné soubory, které zařídí, že to tak může být dál, podle mě nebolí (a "dokonalost" vydání nijak zvlášť nehyzdí).

Myslím, že např. ve WardenClientReceive.pm by mohlo stačit něco jako:

# OBSOLETE, use WardenClient module directly
package WardenClientReceive;
use WardenClient qw(getNewEvents);
1;

Ahoj Pavle,

to je pekne reseni, nicmene to nebude funkcni, jelikoz po pridani funkcionality automatickeho zjistovani absolutni cesty k modulu WardenClient.pm pomoci FILE doslo ke zmene prototypu funkci getNewEvents, saveNewEvents. Nyni se jim predava uz jen reference na udalost (sub saveNewEvent) a pozadovany typ (sub getNewEvents). Prvni argument (cestu k modulu) tim padem ted v tech slepych modulech zahazuji.

Tom

Pavel Kácha wrote:

Myslím, že např. ve WardenClientReceive.pm by mohlo stačit něco jako:

[...]

Rozumím, nezaregistroval jsem, že jsi změnil i prototyp.