Idee für eine Beschleunigung des Autoloaders

[Jens-A. Koch]

Der Autoloader lädt Klassen bei Bedarf automatisch und dynamisch nach.
Allerdings werden dabei sehr viele Dateiprüfungen durchgeführt.
Um die Anzahl an Dateiprüfungen zu reduzieren, könnte man
das jetztige "autoload.log" verwenden, um die Dateipfade
der letztendlich erfolgreich geladenen Dateien in einem Mapping-Array
abzulegen. Ein Pfad-Lookup mittels eines Klassennamens in diesem Array ist wesentlich schneller. Sollte der Klassenname nicht gefunden werden, kann der normale Autoloader als Fallback eingreifen. Das Update des Mapping-Arrays erfolgt mittels arrays_merge,
wobei das mapping-array mit dem aktuellen autoloading array verschmolzen wird.
Im Laufe der Zeit und nach mehreren Applikationsaufrufen sollte sich ein relativ vollständiges Mapping einstellen. Mit anderen Worten: der Autoloader deaktiviert sich schrittweise selbst!

[xsign.dll]

Gute Idee, aber zu komplex fürs vorankommen. Rudimentäre Dinge haben imho vorrang. Autoloader ist nur ein untergeordneter Schritt zum Erfolg, an dem ich leider nicht beitragen kann (Sry Jens fürn Ausraster letztens *g*)

[Jens-A. Koch]

Hi Flo, Die Idee hört sich evtl. komplex an, ist jedoch sehr einfach zu lösen. Ich hab noch ein wenig Zeit dafür und folglich dürfte der Commit irgendwann heute Abend auflaufen. Lass Dich überraschen. Ich bin gespannt was Du dann dazu sagst.
(Auf die besagte Situation möchte ich hier nicht näher eingehen, daher: icq/mail/pn).

[xsign.dll]

kk - poste einfach, was du letztlich verändert hast.

[Jens-A. Koch]

Verändert habe ich folgendes bzw. hinzugefügt wurden folgende Features:

1 Autoload Logging im Debug Mode

Erfolgreiche Autoloads landen in der File /log/autoload_hits.log und nicht erfolgreiche Loads in der File /log/autoload_misses.log.

Nebenbemerkung: Wenn wir unterstellen, dass Clansuite ein nur mittelgroßes CMS/Framework ist und wir schon Loadversuche im Zahlenbereich von 300+ haben, dann möchte ich gar nicht wissen, wie hoch die Anzahl der Misses bei anderen Frameworks aussieht.

2 Dynamisches Autoload Mapping

Ein erfolgreicher Autoload (also ein Durchlaufen aller Pfade, bis die Datei gefunden wird) führt zu einem Eintrag in der allgemeinen Autoloading Map Datei. Beim nächsten Request an das System, wird die zu ladende Datei anhand des Klassennamens in der Mappingfile identifiziert und auch geladen. Es entsteht ein 1:1 Mapping von Klassenname zu Dateiname. Ein Laden aus der Mapfile hat dabei Vorrang vor dem Durchprobieren.

Die Autoloading Map Datei "/configuration/autoload.config.php" besteht aus Dateikopf und dem serialisierten Array. Sie wird bei Objektinstanzierung (also innerhalb des constructor) geladen. Die Objektinstanzierung kann dynamisch erfolgen (via "new") oder statisch (via getInstance (Singleton)).

3 Einige statische Aufrufe entfernt

Um die Map im Clansuite_Loader Objekt zu halten, habe ich auf die statischen Aufrufe verzichtet und diese entfernt.

4 Ausschluss von Doctrine Files

Neu hinzugekommen ist auch der Ausschluss von "Doctrine" Klassen,
außer unserer "Clansuite_Doctrine", aus beiden Autoloading-Strategien.
D.h. es wird nicht sinnlos im Clansuite Autoloader nach Doctrine Kram gesucht.

5 @todo

a) Die Filter werden nicht in die Map übernommen.
b) Das Laden von Modulen wird über loadModul() abgewickelt. Das könnte man ebenfalls
in die Map miteinbeziehen.
c) Evtl. neben Doctrine auch Smarty rausfiltern.

6 Source

Der Quellcode der Datei ist unter
http://trac.clansuite.com/browser/trunk/core/bootstrap/clansuite.loader.php
abrufbar.

[Jens-A. Koch]

Das Zend Framework entdeckt Autoloading per ClassMapping....
http://weierophinney.net/matthew/archives/244-Applying-FilterIterator-to-Directory-Iteration.html

[paulbr]

Wenn ich mich da mal Melden kann

4 Ausschluss von Doctrine Files
Neu hinzugekommen ist auch der Ausschluss von "Doctrine" Klassen,
außer unserer "Clansuite_Doctrine", aus beiden Autoloading-Strategien.
D.h. es wird nicht sinnlos im Clansuite Autoloader nach Doctrine Kram gesucht.

Da stimmt so nicht

Beim überprüfen der autoload_misses.log hatte ich jede Menge Doctrine Klassen da
drinnen stehn, welche in allen Möglichen Ordnern gelistet waren.
z.b.
 ...\core\CsSession.php
 ...\core\filters\CsSession.php
 -- usw. --
nur um mal eine zu nennen.

Deshalb ja der Vorschlag wie in meinem Post erwähnt erst zu Prüfen ob das File existiert.
Wenn ja dann kann das aufgenommen werden, wenn nicht wird das übergangen.

Ich finde nicht das der autoloader zu langsam ist, wenn man wie erwähnt das überflüssige
weglässt.

Ich finde im gegenteil das der autoloader schneller als der von zend arbeitet, da dieser
den dateiort anhand des Klassennamens ermittelt und dann die datei lädt und die Klasse
instanziert. Hierzu muss jeder Klassenname erst zerlegt werden um den Speicherort zu
ermitteln.

Bei clansuite sind feste Strukturen der Ordner, somit muss das ja nicht erst ermittelt werden.
Man prüft nur ob die datei existent ist und lädt diese dann.

gruss
Paul

[Jens-A. Koch]

4 Ausschluss von Doctrine Files
Neu hinzugekommen ist auch der Ausschluss von "Doctrine" Klassen,
außer unserer "Clansuite_Doctrine", aus beiden Autoloading-Strategien.
D.h. es wird nicht sinnlos im Clansuite Autoloader nach Doctrine Kram gesucht.

Da stimmt so nicht

Also mit Doctrine Klassen sind alle zur Bibliothek Doctrine gehörenden Dateien gemeint.
Es sind nicht Models bzw. Records gemeint. Doctrine hat ein eigenes Autoloading.
Damit sich die Suche nach den Dateien nicht doppelt, schließe ich die "Doctrine_" Dateien aus.
Nicht ausgeschlossen wird die Clansuite_Doctrine Klasse - diese initialisiert ja Doctrine.

Records enthalten nicht "Doctrine" im Klassennamen - nur "Cs" als Prefix.
Man könnte natürlich überlegen, ob man auf diesen (oder einen längeren, etwa CsRecords_)
Prefix prüft, um die Records vom Clansuite-Autoloading auszuschließen.
Damit umgeht man dann ebenfalls die Autoloading-Dopplung.
Die Records tauchen ja nur als Misses auf, weil der Clansuite Autoloader zuerst registriert wurde.
Er wird folglich auch zuerst durchlaufen - wird aber kein Model/Record finden, da es keine Strategie dafür gibt. Es kommt zu Misses. Danach gehts dann erst mit dem Doctrine Autoloader für Models weiter.

Autoloader für die allgemeinen Records wird in doctrine.core.php gesetzt
Doctrine_Core::loadModels(ROOT . 'myrecords/', Doctrine_Core::MODEL_LOADING_CONSERVATIVE );
Autoload für Records von Modulen wird in modulecontroller.core.php gesetzt, dort die
Funktion initModel().

Du kannst dir ja mal das alte Verfahren des Autoloading ansehen.
Dort gab es pro Verzeichnis eine Autoloading Strategie.
Diese wurden auch einzeln registriert und nacheinander durchlaufen.
Immer mit Prüfung mittels der Methode requireFile(), ob die gewünschte Datei existiert
 - wenn ja, wird sie geladen. Wenn Du mal einen Blick auf das alte Verfahren werfen möchtest:
http://trac.clansuite.com/browser/trunk/core/bootstrap/clansuite.loader.php?rev=4000

Das jetztige Verfahren kombiniert die einzelnen Autoloading Strategien in ein Pfad-Array.
Dieses Pfad Array wird durchlaufen und es wird getestet, ob die Datei an einem dieser Pfade
existiert. Wenn ja, dann erfolgt ein Map Eintrag. Beim nächsten Durchlauf wird kein Pfad-Array mehr gebraucht, weil die Datei über das Mapping geladen werden kann.

Zur Autoloading-Geschwindigkeit: Autoloading ist immer langsamer als manuelles Loading - direkt an Ort und Stelle. Aber man möchte halt etwas Komfort haben.. Das schnellste Autoloading besteht darin
eine vollständige Lookup-Tabelle (also die Beziehung Klassenname zu Pfad/Datei) vorzuhalten.
Das wäre auch machbar: ein kompletter Include-Durchlauf über alle Clansuite-Dateien und anschließend Klassennamen rausfiltern, Map aufbauen - fertig. Könnte man auch per BuildJob machen.

Soviel erstmal zum Autoloading...

[paulbr]

Das die Doctrine Records, also die 'Cs' definitionen per Autoload im doctrine core geladen werden
habe ich gesehen.
Deshalb bin bin ich ja der Meinung, das in den Clansuite Autoloader diese rausgenommen werden
sollen, den warum unnötigerweise Ressourcen verschwenden wenn es nicht sein muss.

Ich denke man braucht gar keine Änderung bzgl. der Namen machen (CsRecords_), den alles
was regulär mit dem Clansuite Autoloader geladen werden soll sind Klassen die niemals mit 'Cs'
beginnen.

Von daher könnte man direkt am Anfang der Autoload Funktion bereits darauf abprüfen, so das hier
gar nicht erst der Versuch diese zu Laden aufkommt.

Man könnte ja ein Array für Ausnahmen erstellen, welches bei Bedarf erweitert werden kann.
z.B. $disload( 'Cs', '...', '...' ) oder in ähnlicher Form.

Und dann einfach den Anfang des Klassennamens auf die Länge des jeweiligen Array-Items auf
gleichheit prüfen. So bleibt das flexibel und jederzeit erweiterbar.

gruss
Paul

[Jens-A. Koch]

Ok - also Doctrine_Records (Prefix "Cs") im Autoloader rauswerfen - das hebt die Dopplung auf.
Die Änderungen betreffen die Methode autoloadExclusions().

Habe ne kleine Array Prüfung eingebaut. Klassennamen mit entsprechenden Bestandteilen (so wie im Array definiert) werden nun vom Autoloading ausgeschlossen. http://trac.clansuite.com/changeset/4622

gruss jens

[xsign.dll]

Ich versteh das echt nicht... kann man sich denn nichtmal auf das wesentliche beschränken? Die Klassifikation und Optimierung des Autoloaders ist nun wahrlich zweitrangig. Das ist als würde man die ganze Zeit die Klimaanlage eines Autos optimieren wollen, obwohl es noch nichtmal fährt...

[paulbr]

Ja im Prinzip hast du Recht, aus Anwender Sicht zum gegenwärtigen Stand der Entwicklung gesehen!

Grundsätzliches
Allerdings habe ich in meinen 25 Jahren Berufserfahrung eines gelernt, eine saubere Struktur und ein
Optimierter und gut konzipierter Systemkern hat Priorität vor allem anderen. Den wenn hier
vernachlässigt wird oder gedacht wird "kann man ja noch immer wenn das Teil mal läuft", hat man es,
je umfangreicher das System wird, immer schwerer nachträglich Änderungen und verbesserungen
durchzuführen. Das ist jetzt nicht speziell auf dem Autoload bezogen, sondern generell gemeint.

Ich weiss zum Beispiel heute noch, wenn mich ein Kunde anruft, den ich vor 10 Jahren ein Online-System
Programmiert habe, sofort wo der Fehler zu finden ist, nur anhand seiner mehr oder weniger diletantischen
Fehlerbeschreibung. Das funktioniert aber nur wenn eine saubere Modulare Kapselung eine durchdachte
Systemstruktur vorliegt.

Deswegen auch, wenn ich hier grad mal abtrifften kann, das in meinem Posting erwähnte Strukturieren
der Templates. Ich hab mich da mal paar Stunden dran versucht, bin aber gescheitert.
Weil das nutzen der Smarty RenderEngine sich in Prioritärer form durch die gesamte Programmierung
zieht. Wenn man Schnittstellen macht, so sollten diese auch Nutzbar sein ohne das gesamte System
neu durchzuarbeiten und an vielen Stellen umzuprogrammieren.
Das meinte ich mit Nachträgliche Änderungen, sie rechtfertigen kaum den Aufwand, da diese sehr
Zeitintensiv sind. Vieles muss um-/ neuprogrammiert werden etc...

Zum Thema
Zum Autoload soviel, ich habe mir mal den Spass gemacht, eine Routenverfolgung einzubauen.
Du wirst es kaum glauben, aber durch die Änderungen welche jens im Autoloader gemacht hat,
werden die Aktivitäten der Autoload funktionen auf etwa 1/5 reduziert
(grob gerechnet, kann auch was mehr sein).

Ich denke das ist ein Faktor der es durchaus rechtfertigt sich damit auseinander zusetzen

gruss
Paul

[Jens-A. Koch]

kann man sich denn nichtmal auf das wesentliche beschränken

Ich habe in der Roadmap festgelegt, was ich als wesentlich erachte. Vorschläge zur Abänderung der Roadmap kannst Du gerne bringen.  Man kann die Dinge auch immer anders gewichten und eine andere Reihenfolge bei der Abarbeitung wählen. Welche Reihenfolge würdest Du vorschlagen - was ist für Dich wesentlich?

Das Autoloading gehört nunmal zum Core. Andere sehen Verbesserungen im Autoloading auch als wesentlich an (siehe Zend; wenn auch ein Jahr später). Ich denke die Kritik daran geht völlig ok.
Zudem bin ich sehr froh, dass diese Missstände überhaupt von jemandem angesprochen werden.
Dazu muss man auch erstmal Zeit investieren, um das Verfahren zu verstehen, Mängel aufzulisten und Verbesserungen vorzuschlagen oder diese sogar zuzuschicken. Die kleinen Änderung waren geeignet, um noch ein bisschen mehr Performance rauszuholen (siehe Angaben zur Routenverfolgung - wie hast Du die umgesetzt?).

Um die angesprochenen Verbesserungen beim Rendering kümmern wir uns in einem anderen Thread.

Gruß Jens

[xsign.dll]

Ja im Prinzip hast du Recht, aus Anwender Sicht zum gegenwärtigen Stand der Entwicklung gesehen!

Ich bin leider Gottes kein Anwender - schlichtweg Projektleiter und Programmierer. Der aktuelle Stand der Entwicklung von Clansuite ist, dass es keinen "Stand" gibt, sondern nur ein Pre-Pre-Alpha.

Allerdings habe ich in meinen 25 Jahren Berufserfahrung eines gelernt, eine saubere Struktur und ein Optimierter und gut konzipierter Systemkern hat Priorität vor allem anderen. Den wenn hier vernachlässigt wird oder gedacht wird "kann man ja noch immer wenn das Teil mal läuft", hat man es, je umfangreicher das System wird, immer schwerer nachträglich Änderungen und verbesserungen durchzuführen. Das ist jetzt nicht speziell auf dem Autoload bezogen, sondern generell gemeint.

Das ist schön gesagt, aber absoluter Schwachsinn - sry. 20 Jahre Forschung in einem speziellem Gebiet rechtfertigen sich nicht dadurch, dass man permanent Verbesserungen an der Basis der Forschung vornimmt. Die Forschung definiert sich im Endziel dadurch, dass es überhaupt erstmal ein Endziel gibt. Dabei ist die Ausgangslage fest definiert, und nicht wie aktuell vollkommen variabel. Ein klarer Cut wurde schon mehrfach von mir angesprochen, doch nie durchgeführt... das liegt schlichtweg an der Experimentierfreudigkeit der Entwickler und dem mangelndem Scharfsinn für die Fertigstellung eines Produktes bzw. eines Major Releases.

Tatsache ist, dass man mit 1-2 Mann an Entwicklern nie Schritt halten kann mit konkurierenden Plattformen. Zumindest nicht im Hinblick auf Core-Optimierungen. Daher sind klar definierte Schritte notwendig, die sich auch realisieren lassen. Optimierungsarbeiten stehen dabei nicht wirklich auf der Agenda. Es geht generell erstmal um die Fertigstellung.

Ich weiss zum Beispiel heute noch, wenn mich ein Kunde anruft, den ich vor 10 Jahren ein Online-System Programmiert habe, sofort wo der Fehler zu finden ist, nur anhand seiner mehr oder weniger diletantischen Fehlerbeschreibung. Das funktioniert aber nur wenn eine saubere Modulare Kapselung eine durchdachte Systemstruktur vorliegt.

Deswegen auch, wenn ich hier grad mal abtrifften kann, das in meinem Posting erwähnte Strukturieren der Templates. Ich hab mich da mal paar Stunden dran versucht, bin aber gescheitert. Weil das nutzen der Smarty RenderEngine sich in Prioritärer form durch die gesamte Programmierung zieht. Wenn man Schnittstellen macht, so sollten diese auch Nutzbar sein ohne das gesamte System neu durchzuarbeiten und an vielen Stellen umzuprogrammieren. Das meinte ich mit Nachträgliche Änderungen, sie rechtfertigen kaum den Aufwand, da diese sehr
Zeitintensiv sind. Vieles muss um-/ neuprogrammiert werden etc...

Auch hier bleibt mir nur die Aussage: Ohne ein fertiges System, wird kaum eine Beurteilung der Engine möglich sein, da sich der Status Quo faktisch permanent ändert. Zudem läuft man via Template-Engine immer in ein klassisches und logisch nachvollziehbares Problem: Es ist nicht (automatisch) updatefähig. D.h. konkret: Entweder entzieht man dem User die Kontrolle über Templates (schlechte Idee - vorallem im Hinblick auf die Marktdurchdringung), oder man nimmt eine fehlende Patchbarkeit in Kauf.

Alles in allem fehlt es nicht an Know-How. Es fehlt an 2 Eiern und dem Willen zum fertigen Produkt. Nichts für Ungut...

[Jens-A. Koch]

Das sind teilweise berechtigte Einwände. Grundsätzlich entspricht das ja unserem alten Motto: "In guten Zeiten waren wir ein starkes Team und in schlechten Zeiten flogen schon immer die Fetzen.".
Die letzte Komponete die wir gemeinsam erstellt haben, war das Datagrid - und das war gute Teamarbeit. Daran sollten wir anknüpfen. Schon mal aufgefallen, dass hier ausser Dir oder mir niemand wesentliche Komponeten angepackt hat? Richtig is, wir haben das Know-How.. aber es fehlt etwas an Personal und Planung. Aber wandle Deine Vorwürfe bitte mal in konstruktive Kritik.

Daher sind klar definierte Schritte notwendig, die sich auch realisieren lassen.

Dann mal los... Welche Schritte würdest Du als nächstes machen? Ich bin offen für Vorschläge, wie vorzugehen ist. Lass uns darüber reden und festlegen was zu tun ist. Ich würde ne TS-Session dazu vorschlagen.

Um jetzt mal konkret von Nebenkriegsschauplätzen auf den Hauptplatz zu wechseln:
a) Login + Rechtesystem
b) Von SQL auf Doctrine Fixtures umstellen bei der Installation.
Diese beiden Dinge würden uns enorm vorwärts bringen.

Du kannst Dich gerne einbringen, um in Richtung Fertigstellung zu gehen. Fertig wird es aber nur, wenn man auch dran arbeitet. Fakt ist: hier ist Arbeit reinzustecken. Ich arbeite an den Komponenten die ich gerne im System haben möchte: zuletzt ist das Routing reingekommen. Richtig ist der Einwand, das zwischen Komponenten die man "gerne" drin hat und notwendigen Schritten zu unterscheiden ist. Den Vorwurf muss ich mir gefallen lassen - aber ich denke die Neuerungen sind insgesamt not bad at all ,)

Ein klarer Cut wurde schon mehrfach von mir angesprochen, doch nie durchgeführt..

Wie sieht dieser klare Cut aus? Ich würde hier sagen, dann "branche" doch den "trunk" und mach die harten Schnitte die Du als wesentlich ansiehst - oder hilf mir im "trunk" die Dinge einzufrieren und in Richtung Fertigstellung zu gehen.

Ich bin dankbar für die Fehlermeldungen von Paul. Pauls Einwand als Schwachsinn zu bezeichnen geht völlig fehl! Er hat hier klar gesagt, was zu tun is und wie er sich die Sache vorstellt und auch Sourceode beigetragen. Richtig ist an dem Einwand, dass zwar RenderEngine-Adapter vorliegen, sich das gesamte System aber eigentlich auf Smarty stützt. Ich hab mich zu sehr auf Smarty festgelegt.
Um so mehr ist das Ablösen davon wichtig, sonst machen die Adapter keinen Sinn!
Nächträglich wäre das nur sehr schwer zu machen - aber das ist es auch jetzt schon.
Aber: man kann sich auch nur auf einen Renderer beschränken und damit erstmal fertig werden - und das is, so denke ich, was Flo eigentlich meint.

Insgesamt weit ab vom Autoloading - aber eine Diskussion die sich lohnt.

[xsign.dll]

Das sind teilweise berechtigte Einwände. Grundsätzlich entspricht das ja unserem alten Motto: "In guten Zeiten waren wir ein starkes Team und in schlechten Zeiten flogen schon immer die Fetzen.".

Kommt in etwa hin

Die letzte Komponete die wir gemeinsam erstellt haben, war das Datagrid - und das war gute Teamarbeit. Daran sollten wir anknüpfen. Schon mal aufgefallen, dass hier ausser Dir oder mir niemand wesentliche Komponeten angepackt hat? Richtig is, wir haben das Know-How.. aber es fehlt etwas an Personal und Planung. Aber wandle Deine Vorwürfe bitte mal in konstruktive Kritik.

Das sollen ja keine Vorwürfe sein. Ich entwickle ja nicht aktiv mit - versuche aber dennoch die rote Linie in diesem Projekt zu finden. Aber genau diese rote Linie gibt es nicht. Es gab schon vor 2 Jahren eine Roadmap, doch diese wurde immer wieder aktualisiert und über den Haufen geworfen. Das bringt doch nix...

Dann mal los... Welche Schritte würdest Du als nächstes machen? Ich bin offen für Vorschläge, wie vorzugehen ist. Lass uns darüber reden und festlegen was zu tun ist. Ich würde ne TS-Session dazu vorschlagen.

Du bist leider gerade offline, daher hier im Forum:
Klar definierte Schritte sind aus meiner Sicht folgende:
#1 Termine setzen für Entwicklungen
#2 Core freezen
#3 Features für Beta1 setzen
#4 Termine nur im Notfall verschieben (performance issues, minor bugs etc. sind kein Notfall)
#5 Releases ordentlich deployn (demo, zugangsquellen, press-releases, issue response opportunities klar kommunizieren etc.)

Um jetzt mal konkret von Nebenkriegsschauplätzen auf den Hauptplatz zu wechseln:
a) Login + Rechtesystem
b) Von SQL auf Doctrine Fixtures umstellen bei der Installation.
Diese beiden Dinge würden uns enorm vorwärts bringen.

Auch hier wäre für mich Doctrine erstmal zweitrangig. Klar benötigt man einen festen Core (irgendwann), aber warum soll dieser denn jetzt schon stabil sein, wenn noch kein Schwein die Engine überhaupt aktiv benutzt? Hier geht es ja wirklich nur im Beta Releases. Und wenn es eben 20 Betas gibt, dann sei es eben so. Die Patchbarkeit kann man bei Betas wahrlich vernachlässigen - dazu reicht ne Readme aus.

Du kannst Dich gerne einbringen, um in Richtung Fertigstellung zu gehen. Fertig wird es aber nur, wenn man auch dran arbeitet. Fakt ist: hier ist Arbeit reinzustecken. Ich arbeite an den Komponenten die ich gerne im System haben möchte: zuletzt ist das Routing reingekommen. Richtig ist der Einwand, das zwischen Komponenten die man "gerne" drin hat und notwendigen Schritten zu unterscheiden ist. Den Vorwurf muss ich mir gefallen lassen - aber ich denke die Neuerungen sind insgesamt not bad at all ,)

Da kommen wir wieder zu meinem Statement von vor 3 Jahren: Module fertig bekommen. Core-Updates gehören in nen speziellen Zweig. Core-Updates sollten unabhängig vom aktuellen RC sein etc.

Wie sieht dieser klare Cut aus? Ich würde hier sagen, dann "branche" doch den "trunk" und mach die harten Schnitte die Du als wesentlich ansiehst - oder hilf mir im "trunk" die Dinge einzufrieren und in Richtung Fertigstellung zu gehen.

Auch hier hab ich ein Problem: die Zeit. Ich meckere gern (weißt du ja inzwischen ^^), aber kann dir einfach nicht im Dev helfen, da ich projektspezifisch (zeitlich) massiv gebunden bin.

Ich bin dankbar für die Fehlermeldungen von Paul. Pauls Einwand als Schwachsinn zu bezeichnen geht völlig fehl! Er hat hier klar gesagt, was zu tun is und wie er sich die Sache vorstellt und auch Sourceode beigetragen. Richtig ist an dem Einwand, dass zwar RenderEngine-Adapter vorliegen, sich das gesamte System aber eigentlich auf Smarty stützt. Ich hab mich zu sehr auf Smarty festgelegt.

Klar ging es nicht gegen Paul selbst. Das hat viel tiefgreifendere Ursachen. Vorallem verstehe ich aber auch nicht, warum man den Mainstream ablösen will... Smarty ist eine akzeptierte Engine (für "normale" PHP Entwickler). Dass wir keine normalen Entwickler mehr sind, erlaubt es uns trotzdem nicht, diese Situation zu ignorieren.
Ich habe schon damals gesagt, dass ich von Form-Buildern nichts halte, da die DAUs es nicht verstehen werden und auch niemals nutzen werden. Damit kommt man schlichtweg in eine zu professionelle Schiene, für die dann hintenraus die Manpower für qualifizierte Entwicklung und Support fehlt (selbst Zend hat damit seine Probleme). Für Engines mit hohen Anforderungen braucht es Schulungen und ein Partnernetz. Beides fehlt und wird auch nicht leistbar sein können.

Um so mehr ist das Ablösen davon wichtig, sonst machen die Adapter keinen Sinn!
Nächträglich wäre das nur sehr schwer zu machen - aber das ist es auch jetzt schon.
Aber: man kann sich auch nur auf einen Renderer beschränken und damit erstmal fertig werden - und das is, so denke ich, was Flo eigentlich meint.

Genau. Einer für alle ;-) Damit haste schonmal nen guten Milestone.

[Jens-A. Koch]

Ich meckere gern (weißt du ja inzwischen ^^)

Joa, weis i doha. Bisch halt a olla Grantler. ,)

Klar definierte Schritte sind aus meiner Sicht folgende:
#1 Termine setzen für Entwicklungen
#2 Core freezen
#3 Features für Beta1 setzen
#4 Termine nur im Notfall verschieben (performance issues, minor bugs etc. sind kein Notfall)
#5 Releases ordentlich deployn (demo, zugangsquellen, press-releases, issue response opportunities klar kommunizieren etc.)

#1 Termine setzen
Kurz: "Funzt nich.". Im Laufe dieses Projekts hab ich die Erfahrung gemacht, dass Du das komplett vergessen kannst. Es funktioniert auch mit Terminen für Leistungmerkmale nicht - wir hatten es ja eine Weile so. Und ich würde sogar so weit gehen es vorsichtig zu verallgemeinern: es funktioniert bei Open-Source Projekten eher nicht. Und wenn, dann erst ab einer bestimmten Größe des Entwicklerteams und auch nur wenn alle sich einigermaßen "gebunden" fühlen oder es zwei-drei hauptamtliche Kräfte gibt, um am selben Strang zu ziehen und um die zentrale Steuerung zu leisten. Innerhalb dieses Projekts kann ich jedenfalls dritte Personen (auch so schon) nicht "binden", warum also auch noch "terminlich".

Auch hier hab ich ein Problem: die Zeit. Ich meckere gern (weißt du ja inzwischen ^^), aber kann dir einfach nicht im Dev helfen, da ich projektspezifisch (zeitlich) massiv gebunden bin.

Standardantwort auf Mitarbeitsanfragen in ICQ: "Hab keine Zeit - melde mich, wenn ich wieder Zeit für Clansuite hab." Das Argument, keine Zeit zu Haben, gilt ja immer und jederzeit.
Ich bin auch in andere Sachlagen eingebunden und könnte auf Zeitprobleme abstellen. Allerdings wirst Du das nie von mir hören. Mein Commitment zu diesem Projekt ist regelmäßig und wird auch so bleiben.

Was im Hinblick auf Termine allerdings erfahrungsgemäß gut funktioniert ist,
dass man sich bspw. zu einem Wochendtermin zusammenfindet und nur an einer Komponente arbeitet. Den Fall kennst Du; das war immer produktiv; und auf dem Weg wurden noch neue Ideen eingesammelt.

#2 - Core freezen
Den Core kann ich nicht freezen, solange Leistungsmerkmale fehlen, die in den Modulen gebraucht werden. Geschichten wie Routing und Dispatching betreffen fast nur das Framework, kaum die Module (mal Abgesehen von Routing-Regeln).

Module fertig bekommen. Core-Updates gehören in nen speziellen Zweig. Core-Updates sollten unabhängig vom aktuellen RC sein etc.

Du würdest also den Core bzw. das Framework rausnehmen und in einen extra Zweig legen?

#3 - Features für Beta1 setzen
Ich bleibe in der Arbeitsreihenfolge und bei den Features in der Roadmap.
Das führt erstmal zu einer 0.3alpha Version. Du hast insoweit Recht mit pre-Alpha.
Nach dem Routing kommt nun Gettext an die Reihe.

Ich habe schon damals gesagt, dass ich von Form-Buildern nichts halte, da die DAUs es nicht verstehen werden und auch niemals nutzen werden. Damit kommt man schlichtweg in eine zu professionelle Schiene, für die dann hintenraus die Manpower für qualifizierte Entwicklung und Support fehlt (selbst Zend hat damit seine Probleme). Für Engines mit hohen Anforderungen braucht es Schulungen und ein Partnernetz. Beides fehlt und wird auch nicht leistbar sein können.

Sag sowas nich ,) Bei Form-Buildern geht es um Vereinfachung. Klar, diese Dinge sind in der Herstellung und Pflege relativ komplex. Aber Drag'n'Drop verstehn zumeist auch DAUs.
Und wie man an deren Systemen sieht (Joomla, Typo), machen sich solche Techniken nich schlecht, um User und Entwickler zu gewinnen und auch zu halten.

Zeit für ein kleineres Progtoberfest.