Przerobienie ładowania configów

[maciejlew]

Chciałbym zrobić na nowo ładowanie configów. Zamiast globalnej tablicy $CONFIG dostępny byłby singleton LMSConfig. Byłaby możliwość ładowania ustawień z plików ini oraz bazy danych, z możliwością rozszerzenia na inne źródła w przyszłości.

Przykładowe użycie wyglądałoby następująco:

LMSConfig::getConfig()->getSection('directories')->getVariable('sys_dir');

LMSConfig::getConfig(array('lms_ini_path' => '/etc/lms/lms2.ini'))->getSection('directories')->getVariable('sys_dir');

LMSConfig::getIniConfig()->getSection('directories')->getVariable('sys_dir');

LMSConfig::getConfig()->getSection('jakas_sekcja_z_bazy')->getVariable('jakas_wartość_z_bazy');

LMSConfig::getDbConfig()->getSection('jakas_sekcja_z_bazy')->getVariable('jakas_wartość_z_bazy');

Zanim zacznę pisać to może ktoś ma jakieś spostrzeżenia do tego pomysłu?

[gacopl]

Rozmiem, że skrypty też przerobisz ? nie tylko php ?

W dniu 15 czerwca 2014 16:03 użytkownik Maciej Lew <notifications@github.com

napisał:

Chciałbym zrobić na nowo ładowanie configów. Zamiast globalnej tablicy $CONFIG dostępny byłby singleton LMSConfig. Byłaby możliwość ładowania ustawień z plików ini oraz bazy danych, z możliwością rozszerzenia na inne źródła w przyszłości.

Przykładowe użycie wyglądałoby następująco:

LMSConfig::getConfig()->getSection('directories')->getVariable('sys_dir');

LMSConfig::getConfig(array('lms_ini_path' => '/etc/lms/lms2.ini'))->getSection('directories')->getVariable('sys_dir');

LMSConfig::getIniConfig()->getSection('directories')->getVariable('sys_dir');

LMSConfig::getConfig()->getSection('jakas_sekcja_z_bazy')->getVariable('jakas_wartość_z_bazy');

LMSConfig::getDbConfig()->getSection('jakas_sekcja_z_bazy')->getVariable('jakas_wartość_z_bazy');

[image: lmsconfig] https://cloud.githubusercontent.com/assets/3950004/3281121/a8349aa0-f495-11e3-84a5-2b2f206804f5.png

Zanim zacznę pisać to może ktoś ma jakieś spostrzeżenia do tego pomysłu?

— Reply to this email directly or view it on GitHub https://github.com/lmsgit/lms/issues/228.

[maciejlew]

W jakim sensie skrypty?

[chilek]

perla można olać. i tak lepiej na php oprzeć skrypty

[gacopl]

tak czy owak backend musi być i najlepiej jakby był spójny z całą resztą

2014-06-15 22:55 GMT+02:00 Tomasz Chiliński notifications@github.com:

perla można olać. i tak lepiej na php oprzeć skrypty

— Reply to this email directly or view it on GitHub https://github.com/lmsgit/lms/issues/228#issuecomment-46127623.

[chilek]

przeniesienie backendu w 100% na php pozwoli nie deduplikację kodu.

[gacopl]

jestem za :), tylko nie bylo czasem tak, że Perl jest szybszy od PHP? czy się coś w tej materii zmieniło od php5.2?

2014-06-15 23:00 GMT+02:00 Tomasz Chiliński notifications@github.com:

przeniesienie backendu w 100% na php pozwoli nie deduplikację kodu.

— Reply to this email directly or view it on GitHub https://github.com/lmsgit/lms/issues/228#issuecomment-46127747.

[maniac777]

Moim zdaniem nie można perla olać do czasu zapewnienia jego funkcjonalności przez PHP. By było łatwiej można uznać część rzeczy za przestarzałe i je porzucić (w szczególności mam tutaj na myśli ipchains i oident). Najbardziej złożony prawdopodobnie byłby rt-parser oraz mgc chociaż w tym drugim wypadku filozofia działania skryptu jest w mojej ocenie mocno niepoprawna.

2014-06-15 22:55 GMT+02:00 Tomasz Chiliński notifications@github.com:

perla można olać. i tak lepiej na php oprzeć skrypty

— Reply to this email directly or view it on GitHub https://github.com/lmsgit/lms/issues/228#issuecomment-46127623.

[maciejlew]

Myślę ze w tym zakresie zachowana będzie wsteczna kompatybilność, zmiany w sposobie czytania zmiennych konfiguracyjnych w PHP nie będą miały wpływu na to co się dzieje w PERL.

Przepisanie wszystkiego na PHP jest moim zdaniem dobrym pomysłem. Pozbędziemy się redundancji kodu, o wiele łatwiej jest o programistów PHP niż PERL więc istnieje większe prawdopodobieństwo że ktoś na to krytycznie spojrzy i będzie umiał poprawić w razie czego.

Jeśli komuś zależy tak na szybkości wykonywania się programu to przepisze go sobie w C/C++ ;)

[maniac777]

Logika powinna być zachowana i spójna pomiędzy częściami kodu. Jak przewidujesz inne miejsca trzymania konfiguracji niż ini i baza, to powinien to przewidywać i perl (o ile będzie nadal używany). Ja swego czasu chciałem doprowadzić do sytuacji w której w ini są trzymane same namiary na bazę danych (sekcja [database]), a cała reszta jest w niej trzymana, ale trochę czasu mi brakuje.

[gacopl]

Też jestem za tym aby doprowadzic do sytuacji gdzie w ini sa tylko dane do bazy a reszta już jest konfigurowalna w UI

W dniu 16 czerwca 2014 17:31 użytkownik Rafał Ramocki < notifications@github.com> napisał:

Logika powinna być zachowana i spójna pomiędzy częściami kodu. Jak przewidujesz inne miejsca trzymania konfiguracji niż ini i baza, to powinien to przewidywać i perl (o ile będzie nadal używany). Ja swego czasu chciałem doprowadzić do sytuacji w której w ini są trzymane same namiary na bazę danych (sekcja [database]), a cała reszta jest w niej trzymana, ale trochę czasu mi brakuje.

— Reply to this email directly or view it on GitHub https://github.com/lmsgit/lms/issues/228#issuecomment-46193603.

[maciejlew]

Przygotowałem klasy do zarządzania konfigami (oddzielny pull request). Przy okazji wyszedł mały problem - aby z nich skorzystać w łatwy sposób muszą zostać użyte po załadowaniu autoloadera, a żeby załadować autoloadera należy wiedzieć gdzie on jest - mieć już zdefiniowaną stałą LIB_DIR...

Widzę dwa rozwiązania:

• zrezygnowanie z konfigurowalnych ścieżek - ustalenie domyślnych, jak ktoś chce je zmodyfikować modyfikuje bezpośrednio stałe SYS_DIR, LIB_DIR itp.
• ładowanie sekcji [directories] w starym stylu po czym porzucenie zmiennej $CONFIG na rzecz klasy LMSConfig

[chilek]

Od razu w funkcjach z lib/config.php warto, żebyś uwzględnił zmiany w funkcjach get_conf() i check_conf(). Szkoda byłoby wszędzie w kodzie pisać takie tasiemce jak w przykładzie ;-)

[mruz]

Pozwolę sobie dodać info, że stworzyłem niedawno open source'owy system do administracji siecią mruz/las. Są to dopiero początki i na pewno ustępuje lms, ale może wspólnie dałoby się coś fajnego, nowoczesnego stworzyć? Projekt oparłem o phalcon - nowoczesny, najszybszy framework php napisany w C jako rozszerzenie do PHP, więc z szybkością nie będzie problemów. Więcej info na debian.pl. Co sądzicie, jestem otwarty na kolaborację ;)

[misiek08]

Trochę offtopic, ale @mruz - nie tędy droga. Nie możesz wymagać na ludziach całkiem niestandardowego modułu do PHP. Dlatego właśnie taki Phalcon jest szybki, ale nie ma tak dużo fanów jak Laravel, Smarty, F3, Silex, Slim czy wiele innych :)

[mruz]

No nie wiem, wydaje mi się, że jednak phalcon jest popularny i ma sporo fanów. Patrząc np. na stary na githubie więcej niż wymienione F3, Silex, Slim.. System do administracji instaluje się raczej na maszynie, do której się ma pełen dostęp, więc z dodaniem modułu do php nie powinno być problemów. Przy dobie pakietów to 2 komendy: dodanie repozytorium i instalacja pakietu.

[misiek08]

Twój wybór. Tylko pamiętaj w Wiki i readme/install, żeby napisać o tym fakcie, bo będzie dużo pytań "czemu mi nie działa, skoro wszystko zainstalowałem zgodnie z instrukcją?" Takie ostrzeżenie, ja właśnie dlatego zrezygnowałem z Phalcona, bo szybki on jest tylko jako moduł C. Ogólnie jest wolny jak reszta.

[maciejlew]

"System do administracji instaluje się raczej na maszynie, do której się ma pełen dostęp" - zdziwilibyście się jaką fantazję potrafią mieć ISP :-)

Przeglądałem system stworzony przez @mruz ale zanim dojdzie on do funkcjonalności oferowanej przez LMS minie dużo czasu. Lepiej bybyło poświęcić go na rozwój LMS.

[mruz]

Na hostingach z resztą phalcon też dostępny, nawet polskich.. W gruncie rzeczy mój system oferuje na razie dynamiczne generowanie firewalli.

----- Reply message ----- Od: "Maciej Lew" notifications@github.com Do: "lmsgit/lms" lms@noreply.github.com DW: "Mariusz Łączak" mruz@poczta.onet.pl Temat: [lms] Przerobienie ładowania configów (#228) Data: wt., wrz 9, 2014 19:43

"System do administracji instaluje się raczej na maszynie, do której się ma pełen dostęp" - zdziwilibyście się jaką fantazję potrafią mieć ISP :-)

Przeglądałem system stworzony przez @mruz ale zanim dojdzie on do funkcjonalności oferowanej przez LMS minie dużo czasu. Lepiej bybyło poświęcić go na rozwój LMS.

— Reply to this email directly or view it on GitHub.

[mruz]

@misiek08 co do poularności i szybkości phalcona jeszcze: Best PHP Frameworks for 2014 i prosty benchmark zrobiony na prostym przykładzie, ale widać różnicę: mniej includowanych plików, mniej użytej pamięci, więcej requestów i krótszy czas na request. A tu jeszcze porównanie silników szablonów: Top 5 php template engines. Rozszerzenie z frameworkiem jest ładowane raz przy starcie serwera www, a nie jak w tradycyjnych przy każdym requeście, komponenty siedzą nam w pamięci, a nie za każdym razem dołączamy je i odczytujemy z dysku, co też może spowalniać, dołączane są tylko nasze pliki. ORM napisany w C też pewnie ma niemały wpływ jeśli korzystamy z mapowania.

[maniac777]

Taka aplikacja powinna generować na tyle dużego obciążenia i nie powinna być na tyle zasobożerny by z technicznego punktu widzenia uzasadniony był wybór takiego silnika templateów jak phalcon. Uzasadnione by to było w aplikacji która musi obsłużyć ogromną ilość requestów, ale nie koniecznie w panelu dla ISP po którym klika ograniczona ilość ludzi. Po drugie nawet w "tradycyjnych" systemach które w mniej inwazyjny sposób niwelują część niedogodności o których wspomniałeś. Dla przykładu problem który zdaje się phalcon chce rozwiązać (tj stałe inlcluowanie, otwieranie, parsowanie co request tych samych plików) został już częściowo załatany przez apc/xcache. Wiele problemów w dzisiejszych czasach nie istnieje ponieważ powszechnie wykorzystywane są różne cache w tym najszybszy mi znany cache dyskowy + rewritey (tak jak w we wtyczce do wordpessa wp-super-cache).

W dniu 10 września 2014 07:58 użytkownik Mariusz Łączak < notifications@github.com> napisał:

@misiek08 https://github.com/misiek08 co do poularności i szybkości phalcona jeszcze: Best PHP Frameworks for 2014 http://www.sitepoint.com/best-php-frameworks-2014/ i prosty benchmark http://phalcon-php-framework-documentation.readthedocs.org/en/1.3.0/reference/benchmark/hello-world.html#graphs zrobiony na prostym przykładzie, ale widać różnicę: mniej includowanych plików, mniej użytej pamięci, więcej requestów i krótszy czas na request. A tu jeszcze porównanie silników szablonów: Top 5 php template engines http://www.sitecrafting.com/blog/top-5-php-template-engines. Rozszerzenie z frameworkiem jest ładowane raz przy starcie serwera www, a nie jak w tradycyjnych przy każdym requeście, komponenty siedzą nam w pamięci, a nie za każdym razem dołączamy je i odczytujemy z dysku, co też może spowalniać, dołączane są tylko nasze pliki. ORM napisany w C też pewnie ma niemały wpływ jeśli korzystamy z mapowania.

— Reply to this email directly or view it on GitHub https://github.com/lmsgit/lms/issues/228#issuecomment-55074253.

[mruz]

@maniac777 zgadzam się, że panel ISP może nie mieć aż takich wymagań i cache w tradycyjnych frameworkach wiele poprawia. Zastosowałem może nadmiarowe, ale nowoczesne, łatwe w użyciu narzędzie, które z szybkością nie powinno mieć problemów. Wygląda na to, że to co jest jego największą zaletą może być jednocześnie największą wadą :)

PS. Phalcon ma też różnego rodzaju adaptery cache widoków/zapytań, które to właśnie jeszcze bardziej podnoszą wydajność, ale to do bardziej specyficznych aplikacji może, w których spodziewany jest duży ruch i szybkość jest priorytetem.

[chilek]

Myślę, że można zamknąć już tą sprawę.