index > dokumentace > Ezop-devel shrnutí

ezop-devel; z 9. 9. 2001

Document Type Definition

Podporovat budeme XSD, pro DTD by měl existovat převodník do XSD. Předpokládám, že validace dokumentu (stejně jako jeho případná indexace) se provede při operaci "insert into DOM".

Cache

Není potřeba řešit teď, je potřeba pouze trasparentně navržené API, aby cache šla později vložit mezi dva komunikující objekty. Každopádně tedy žádné explicitní vyrovnávání toku dat uvnitř objektů.

Je potřeba implementovat

• XML parser — zřejmě z čista
• HTTP — bison, flex / ručně?
• Správa paměti
• Drobnosti — binární stromy, hashe apod.

Coding style

• POSIX
• striktně ANSI compliant hlavičkové soubory
• gcc 2.96+; -ansi -pedantic -Wall
• http://developer.gnome.org/doc/guides/programming-guidelines/book1.html — podrobnější informace o coding style

Dokumentace

• DocBook XML 4.1.2; http://www.docbook.org
• Kořenový element article (zbytek je zbytečně mocný),
  <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1.2//EN">
• Preferována angličtina — celý web anglicky, dokumenty samotné podle časových možností.
• Bitmapy v PNG, vektory pokud možno v PDF; nemožno-li, jsem schopen rozumná zvěrstva (PS, tradiční vektory) převést do PDF.

TODO: Nějaký balík pro generování dokumentace ze zdrojáků. Měl by mít výstup ideálně v XML, v horším případě alespoň nějakou rozumně parsovatelnou strukturu, aby se dala převést do DocBooku a sjednotit se zbytkem dokumentace.

Konfigurace

Rozhodně v XML, detaily zjevně až později.

Předávání parametrů, proměnné HTTP apod.

Pro předávání proměnných spojených s HTTP protokolem (neupínáme my se moc na ten HTTP? respektive, vadí to, že se upínáme? :) bude vytvořen poduzel zpracovávaného uzlu, ve kterém budou ve stromové struktuře uloženy jednotlivé parametry (proměnné prostředí, cookies apod.).

TODO: práce se stromem ve skriptech. Na tom jsme se příliš neshodli, respektive nedotáhli do konce. Zřejmě budou dva stromy: strom pro generování výstupu a strom pro permanentní zásahy na server — je potřeba to vybalancovat co do složitosti, použitelnosti a rychlosti.

Databáze

http://www.faqs.org/faqs/databases/free-databases/ — seznam free databází, bylo by dobré nějakou objektovou alespoň prozatím vybrat. Pokud bude dobře napsané API, není problém databázi vyměnit / napsat nějaký malý nesmysl jen pro testování.

Conclusion

Je potřeba prodiskutovat metodu práce s DOM stromem ve skriptech, to je docela podstatná záležitost. Dále by bylo dobré mít alespoň trochu jasno v databázi (buď udělat něco malého ošklivého pro naše testovací účely nebo najít nějakou free ODB).

Otázku API by bylo též vhodné prodiskutovat — nakolik síťově oddělit části (DB / resolvery / jádro), jakým způsobem vyměňovat data (XML / SOAP?)? Dál: kontrola output filtrů — nějaký nadřazený proces (Ezop core), nebo to nechat na domluvě jednotlivých filtrů, případně ponechat část kontroly nad výsledkem skriptům?

Pak bych byl pro několik praktických sond (alespoň mě by to pomohlo) — napsat pár dokumentů z praxe a projít s nimi krok za krokem celým Ezopem. Vyzkoušet praktické řešení tradičních problémů (skiny, cookies, počítadlo, fórum apod.), od HTTP requestu přes transformaci, skripty, až po transformaci na HTML. Nebo máte pocit, že je to zbytečná práce?

Po onom 'praktickém testu idejí' a doladění zmíněných detailů bychom mohli začít programovat — díky mechanismu resolverů a filtrů se dá udělat naprostý základ i bez toho, že bychom si svázali ruce ohledně volby skriptovacího jazyka nebo databáze.

index > dokumentace > Ezop-devel shrnutí