Narazie prace nad moim rozszerzeniem stanęły w miejscu, ale poszukując informacji nt. budowy takowego znalazłem pare ciekawych artykułów i wszystkie oscylują wokół wykonywania php i przetwarzania kodu na wewnętrzną reprezentację Zend engine, czli opcode’y (nie wiem jaki jest odpowiednik po polsku), oto one.
Na początek wspominana już wcześniej przeze mnie Sarah Golemon i jej wprowadzenie do opcodeów. Później Terry Chay (chyba, wniskuję z nazwy domeny) opisuje swoją batalię z Zend enginem. Następnie lista opcodeów z opisem i wytłumaczeniem. I ostatni z nich, czyli jak są Zend engine przetwarza tablice.
A wszystko zaczęło sie od tego, że zacząłem sie zastanawiać jakby tu udoskonalić jakiś system szablonów np. Smarty. Pierwszy strzał padł na rozszerzenie języka, dystrybuowane jako pliki źródłowe, kompilowane dynamicznie (jako .so), ale teraz myślę, że chyba lepiej by było rozszerzyć sam Zend engine o mapowanie kodów danego języka szablonów, bezpośrednio na opcode’y, ale do tego to jeszcze długa droga.
Są jeszcze 2 rzeczy, które planuje wykorzystać jako drogowskazy. Są to gotowe rozszerzenia php, dostępne przez system instalacji PECL. Jedno z nich to opcode cache, które ma zapewniać, ponowne wykorzystywanie opcodeów, tak żeby nie była potrzebna ich kompilacja – czyli autorzy też musieli się dość mocno wgryźć w sam Zend engine i na to właśnie liczę:)
Druga to już chyba nieco prostsza sprawa: pecl_http , które ma chować cała magię związaną z wysyłaniem i odbieraniem żądania HTTP, a że przeglądałem podobne rozwiązania zarówno w Apache Httpd (ma całkiem miły framework w C do budowania rozszerzeń i filtrów), HttpServletRequest w Javie (specyfikacja Servlet 2.4), kończąc na mojej implementacji (na potrzeby Fligg’a) to doszedłem do wniosku, że pomimo różnic między wszystkimi prezentowanymi rozwiązaniami, łatwiej mi się będzie przegryzać przez rozszerzenie pecl’owe.
No nic zobaczymy jak z czasem będzie, może pecl_smarty kiedyś ujrzy światło dzienne.
