mod_rewrite - watpliwosci

Prace nad przystosowaniem coyote do mod_rewrite sa juz praktycznie na ukonczeniu. Pozostaje jednak pewien drobny problem - w jaki sposob nalezy zaaplikowac cala zmiane do repozytorium CVS. Oto dwa proponowane przeze mnie rozwiazania:

Zmiana zrodel bezposrednio w CVS:
Jest to naniesienie wszystkich poprawek na zrodla znajdujace sie w repozytorium. Co to oznacza? Mniej wiecej tyle, ze nie ma juz odwrotu. Od tego momentu coyote bedzie uzaleznione od mod_rewrite i bez tego nie bedzie dzialac poprawnie. Wymusza to dodatkowo zmiane w developowaniu projektu - programista zamiast linkow skrypt.php?id=12 bedzie zmuszony pisac skrypt.php/id=12 (moze nie jest to wielka sprawa ale bedzie trzeba przywiazywac wiecej uwagi takim rzeczom).

Wstawienie patcha do CVS:
Tytulowy patch jest plikiem ktory powstal dzieki uzyciu programu diff. Do naniesienia patcha na zrodla potrzebny jest program 'patch' standardowo dostepny we wszelkiej masci linuxach/unixach. Caly proces wygladalby tak: sciagamy z CVS wszystkie zrodla, a nastepnie patch`ujemy. Jednak nie ma nic za darmo - uzytkownicy windowsa moga miec problemy gdyz standardowo 'patch' nie jest dostepny. Jezeli jest (pewnie tak :)) odpowiednik windowsowy to nie ma problemu.

Porownanie obu rozwiazan:
Rozwiazanie 1 jest na pewno wygodniejsze, ale jak juz napisalem nieodwracalne. Ma to swoje konsekwencje. Przykladowo osoby, ktore nie moga na swoim serwerze wykorzystac mod_rewrite (brak dostepu do konfiguracji serwera, problemy z .htaccess) beda skazane tylko na starsze wersje systemu 'coyote' gdyz nowsze beda wymagac mod_rewrite dodzialania. Jednak jak wspominalem zalety to wygoda - nie trzeba recznie patchowac zrodel oraz w pewnym stopniu znormalizowanie i ustosunkowanie sie do kwestii mod_rewrite. Jezeli chodzi o 2 rozwiazanie to zastosowanie jest malo wygodne (szczegolnie w przypadku windowsa) ale dochodzi jeszcze jeden problem: patch bardzo szybko stawalby sie nieaktualny. Zmiany w coyote prawdopodobnie powodawalyby powstawanie nie dzialajacych linkow. Wymusilo by to wyznaczenie opiekuna badz opiekunow, ktorzy zajmowaliby sie samym patchem i zaraz po zmianach w kojocie poprawiali odpowiednio patch. 2 rozwiazanie daje rowniez wybor uzytkownikowi - nie chce/nie moze uzywac mod_rewrite to nie stosuje.

Jezeli jestes zwyklym uzytkownikiem 4programmers.net i nie zamierzasz wykorzystywac projektu Coyote do wlasnych celow to ten problem Cie omija - 4programmers tak, czy tak sobie poradzi z mod_rewrite, w przeciwnym wypadku radze zabrac glos w dyskusji.

Jezeli juz, to polecalbym metode 2. Ale obojetnie jaka bedzie - byleby byla po 11 listopada. Wtedy to zostanie publicznie udostepniona baza danych oraz system ze wszelakimi poprawkami i fajnie by bylo aby funkcjonowal jeszcze wtedy na "starych" linkach.

Ja jestem oczywiscie za rozwiazaniem 1. Ale mam jeszcze 2 propozycje do rozważenia (chociaż dosyć skompliowane).
3.
Otóż można napisać (dosyć skomplikowane :() regułki dla sed'a. W CVS przechowywane byłyby źródła bez mod_rewrite, a przed wrzuceniem na serwer przepuszczałoby się przez sed'a i ew. ręcznie poprawiało resztę. Wada tego rozwiązania jest taka, że łatwo wtedy o błąd na serwerze, bo automat nie zawsze dobrze sobie radzi, a 1 (czy nawet kilku ludzi) nie wychwyci wszystkiego (mod_rewrite jest już od jakiegoś czasu testowany u embraced'a i trafiaja się przeoczenia).
4.
Musialyby istnieć 2 linie w CVS. Jeden z mod_rewrite, który odpowiadałby temu, co jest na serwerze (lub ma się pojawić) i drugi bez mod_rewrite, na do którego wprowadzaliby zmiany ci, którzy nie maja możliwości korzystania z mod_rewrite. Raz na jakiś czas dokonywanoby "połączenia" obydwu linii (w RCS jest opcja do automatyzacji tego w możliwie dużym stopniu, więc CVS, jako że był pierwotnie oparty na RCS też powinien mieć). Po takim połączeniu przeprowadzanoby intensywne testy obydwu linii. Byłoby to takie coś w rodzaju zamrażania.

co do 3 rozwiazania:
uzycie sed`a tak, ale tylko do modyfikacji skorek, same skrypty sa zbyt skomplikowane aby zostawic to automatowi (wiem bo przegladalem i modyfikowalem skrypty recznie)

sam jestem za 1 rozwiazaniem.

Niby jestem za trzymaniem jednej kopii - jak będą różne wersje to się wszystko zagmatwa - ktoś poprawi coś w jednej, w drugiej mu się nie będzie chciało i wszystko szlag trafi.

ale...

w tym momencie Coyote stanie się Apache-only - czyli do d**y. Jak jakiś skrypt na stronie jest IE-only to wszyscy psioczą, a tu nagle to samo ma być z całym serwisem.

Jeśli zostanie zmieniony system linków na stałe i stare przestaną być obsługiwane, to ja odpadam jako developer Coyote - pewnie mała strata, bo i tak nic nie robię... (heh)

it's up to you

w tym momencie Coyote stanie się Apache-only - czyli do d**y. Jak jakiś skrypt na stronie jest IE-only to wszyscy psioczą, a tu nagle to samo ma być z całym serwisem.

Tylko, że IE jest tylko na Win i Mac, a Apache jest na troszkę większą liczbę platform... (chociaż nie słyszałem o wersji na stare maki... ale na Mac OS X już na pewno pójdzie).
Gorsze jest chyba to, że Coyote może być uruchamiane na serwerach bez mod_rewrite (albo odpowiednich uprawnien).

ciezko apache zainstalowac? nie. jedynym problemem pozostaje ewentualna niemoznosc wykorzystania mod_rewrite. zreszta mod_rewrite jest dostepny i pod te Twoje 'zakichane' IIS :P wiec czemu apache only? (zaplacic sie nie chce za moda? ;P)

// fakaj się, ja też używam IIS i nie zamierzam znowu instalować Apacha, którego po prostu nie lubię, tak samo nie zamierzam płacić za dodatki do programu, za który nic nie zapłaciłem. ma być patch, inaczej będzie o kolejnego developera mniej - ŁF

Problem rozwiązany - stworzymy oddzielną gałąź w CVS i wszystkie kłopoty znikną.