Roadmap Serendipity 2.0 - Vorschlag

Hier können Probleme und alles andere in Deutscher Sprache gelöst werden.
Post Reply
falk
Regular
Posts: 512
Joined: Tue Sep 27, 2005 10:16 am
Location: DD
Contact:

Roadmap Serendipity 2.0 - Vorschlag

Post by falk »

Hallöchen,

Garvin möchte das ich diese Liste hier poste, also mache ich das. Es geht um meine Zielsetzung für Sy9 2.0. Malte hat mich irgendwie überredet mal wieder am Blog mitzumachen. Folgende Punkte habe ich mir auf die Roadmap geschrieben:

8<-----------------

* Ich möchte die 1.7er und die 2.0er zusammenfügen (am besten bis KW 27)
* Danach baue ich Composer-Unterstützung ein
* Datenbank-Schema-Überarbeitung (mysql)
* Die veralteten PEAR-Bibliotheken werden ausgetauscht (gegen aktuelle oder andere Bibliotheken weiß ich noch nicht).

Dann entscheide ich mich zwischen:

* neuem Datenbank-Layer
* neuer Setup-Routine
* neuem Event-System

Und natürlich ständige Codeoptimierung.
Vor allem möchte ich von den vielen Selbstentwicklungen weg und etablierte Standards einführen. S9y erfindet ständig das Rad neu. Ich finde wir sollten so oft es geht vorhandenen Bibliotheken nutzen und diese über den Composer laden. Solche Sachen wie in vendor-libs rumschreiben möchte ich in Zukunft verhindern.

Das einzige Problem was ich sehe ist die riesige Anzahl von zusätzlichen Plugins. Wenn wir die API aufräumen, müssen die Änderungen nachgezogen werden. Ich glaube ein neues Repo mit 2.0er-Plugins wäre sehr nützlich.
Da können wir auch gleich sehen welche Plugins überhaupt noch gebraucht werden.

8<------------------

Garvin hat Serendipity in diesem Forum als Nischenprodukt bezeichnet. Das finde ich schade, den S9y hat einiges an Potential. Sorgen wir dafür, das dieses Potential auch genutzt werden kann.
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: Roadmap Serendipity 2.0 - Vorschlag

Post by garvinhicking »

Hi!

Das sind ganz schön große Pläne, das klingt eher wie ein ganz neues Blogsystem das dann nicht mehr Serendipity ist, weil es quasi alles über Bord werfen könnte was derzeit funktioniert.

Ich lasse mich aber über die konkreten Implementationsvorschläge gerne überraschen. Ich denke nur es bringt wenig einen ganz frischen neuen Kern zu haben für den es dann keine Plugins gibt, und jedes dafür neu programmiert werden muss. Ich könnte mir vorstellen dass man sich dadurch das neue Backend in der 2.0 etwas untermauert, weil man eigentlich mit einem neuen vollkommen inkompatiblen System startet, anstelle einem System das bestehende Installationen und Plugins weiter nutzen kann. Wir sind ja doch ein kleines System, ich sehe hier jetzt eher den Wunsch einer komplett neuen Engine, vor allem wenn Du schreibst neue Event-System und Composer-Dependencies.

Wie sehen die anderen das? Und was sagen vor allem Nutzer dazu?

Wie hier ja jeder weiß ist für mich BC das größte Gut, mir wäre wichtig das bestehende Plugins mit einer kompatiblen API vom "neuen" Kern unterstützt werden, ähnlich wie das neue Smarty3 auch die Smarty2-Sachen adaptiert hat. Ich fände es daher eigentlich ganz schön wenn man solche "total brechenden" Funktionen eher in eine "3.0" oder einen anders benannten Tree einbaut, um erstmal ein "kompatibles" 2.0 zu haben. Aber ich bin gespannt wie ihr anderen das seht.

Viele Grüße,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Roadmap Serendipity 2.0 - Vorschlag

Post by yellowled »

Ich kann dazu nicht viel sagen, weil ich das meiste, was Falk hier vor hat, technisch nicht verstehe. (Gleichwohl freue ich mich, dass Du „wieder da“ bist.)
falk wrote:Ich möchte die 1.7er und die 2.0er zusammenfügen (am besten bis KW 27)
Ich sehe nicht so richtig die Notwendigkeit dazu (was vermutlich daran liegt, dass ich die technischen Hintergründe nicht verstehe). Im Moment ist der 2.0-branch (so weit ich das beurteilen kann, Malte wird dazu vermutlich mehr sagen können) in erster Linie dazu da, das neue Backend zu entwickeln. Ich kann nicht abschätzen, ob ein Merge die Arbeit am Backend „stören“ würde.
falk wrote:Ich glaube ein neues Repo mit 2.0er-Plugins wäre sehr nützlich.
In die Richtung hatte ich auch schon gedacht. Es ist ja so: Wenn 2.0 (oder welche Version auch immer genau) sowohl in Front- als auch Backend HTML5 ausliefert, wäre es zumindest sauberer, auch die Plugins entsprechend anzupassen, vor allem diejenigen, die neue „Teile“ im Backend erzeugen. Das betrifft auch andere Teile als „nur“ HTML und CSS, z.B. Javascript. Dafür könnte man aber natürlich auch einen versionsbasierten Switch einbauen.

Mit BC ist das so eine Sache. Ich habe immer den Eindruck, ich als Frontendler denke manchmal zwei Schritte weiter als „Ihr“, weil ich diesen ganzen Backendkram nicht bedenken muss bzw. kann. Natürlich ist BC grundsätzlich erstrebenswert. Natürlich wollen wir so wenig Nutzer und Entwickler wie möglich mit einschneidenden Änderungen „vergraulen“, natürlich müssen radikale Änderungen dokumentiert werden (und dazu hat keiner Lust, wenn wir mal ehrlich sind).

Aber gleichzeitig sollten wir (meines Erachtens) auch gucken, dass wir das Ding weiterentwickeln und voran bringen. Nur so kriegen wir mehr Benutzer, mehr Entwickler und damit auch ein zukunftsfähiges System (mal vorausgesetzt, dass das Ziele sind, die wir alle zumindest teilweise verfolgen bzw. für erstrebenswert halten).

YL
mattsches
Regular
Posts: 440
Joined: Sat Nov 05, 2005 9:35 pm
Location: Wiesbaden, Germany
Contact:

Re: Roadmap Serendipity 2.0 - Vorschlag

Post by mattsches »

Whoa, das sind ambitionierte Ziele! Und ich kann sie größtenteils irgendwo nachvollziehen. Ich selbst habe zwar vor, mir bald etwas Zeit freizuschaufeln, um mich wieder mehr mit Serendipity beschäftigen zu können. Aber mich als Backend-Entwickler motiviert der - noch größtenteils für PHP4 geschriebene - PHP-Quellcode nur so mittelmäßig :| Im (Backend-)Frontend haben yellowled und onli seit geraumer Weile ja (mehr oder weniger) Spaß, aber was PHP angeht ... nicht falsch verstehen, es ist ja keinesfalls schlechter Code, nur ist er doch sehr in die Jahre gekommen. Und man möchte als Entwickler doch auch gern all' die coolen neuen PHP-Features benutzen :wink:

Deswegen finde ich viele der von Falk angesprochen Ideen interessant: v.a. Composer-Unterstützung, PEAR-Bibliotheken raus, ggf. neuer DB-Layer. Ich möchte noch ergänzen: Testabdeckung durch Unit-Tests, am besten auch gleich für Plugins.

Nur, und da gebe ich Garvin recht, das wäre ab einem gewissen Punkt bzw. mit der Entscheidung für bestimmte Änderungen dann im Endeffekt ein neues Blogsystem. Ich muss zugeben, dass ich mir auch schon entsprechende Gedanken gemacht habe: Braucht die Welt noch ein neues Blogsystem? Wäre es den Aufwand wert, S9y komplett auf eine wie auch immer geartete modernisierte Code-Basis zu heben? Uns was passiert dann mit den Plugins, die ja ganz entscheidend zur Benutzererfahrung von S9y beitragen? Usw.

Würden wir, das nur als Gedankenspiel, S9y forken und mit einigen Leuten den Fork (nennen wir ihn spaßeshalber "Bartleby") den Vorschlägen folgend weiterentwickeln, käme das bisherige S9y wohl mehr oder weniger zum Stillstand. Bartleby wäre ohne Plugins aber zunächst Yet Another Blog System, ohne besondere Vorteile, ohne den guten Ruf von S9y.

Vielleicht muss es aber auch gar nicht so dramatisch kommen. Wenn erstmal nur die bundled-libs durch eine Composer-Lösung ersetzt werden (und das überhaupt ohne Weiteres möglich ist und dann noch alles funktioniert), wäre das vielleicht ein erster möglicher Schritt. Alle weiteren Vorschläge (DB-Layer, Event-API) greifen aber doch schon sehr tief ins System ein, da müssten wir an sehr vielen Stellen Änderungen vornehmen. Unvorstellbar finde ich das nicht, aber viel Arbeit allemal.

Eine abschließende Meinung kann ich momentan noch nicht abgeben, aber ich finde, wir sollten das diskutieren. Einerseits könnte es Spaß machen, andererseits möchte ich am Ende nicht mit zwei kaputten Systemen dastehen.
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Roadmap Serendipity 2.0 - Vorschlag

Post by yellowled »

mattsches wrote:Wäre es den Aufwand wert, S9y komplett auf eine wie auch immer geartete modernisierte Code-Basis zu heben?
Den Teil verstehe ich nicht. Wieso ist es ein neues Blogsystem, wenn es auf einer modernisierten Codebasis steht? Es ist eine neue Major-Version (2.x). Die alte (1.x) wird irgendwann halt end-of-life erreichen. Wo ist da das Problem?

Gut, es kann Leute geben, die (aus welchem Grund auch immer) weiterhin 1.x fahren wollen (obwohl wir immer predigen, auf dem aktuellen Stand zu bleiben). Für die müsste man Security im Auge behalten und ggf. ein separates Plugin-Repository bereitstellen. Beides müsste (denke ich in meinem frontendlerischen Leichtsinn) ab einem gewissen Punkt doch nicht mehr großartig entwickelt, sondern „nur“ gewartet werden?

YL
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: Roadmap Serendipity 2.0 - Vorschlag

Post by garvinhicking »

Hi!

Nach einer Nacht des Schlafes kann man das vielleicht auch weniger apokalyptisch sehen als mein erstes Bauchgefühl.

Ich denke es sollte möglich sein die neuen Bibliotheken auch abwärtskompatibel einzubauen. Wenn wir bisher als eine PEAR-Library aufrufen nutzen wir ja meist immer nur 1-2 "öffentliche" Methoden, teilweise sogar in s9y kernfunktionen (serendipity_request_start) gebündelt. Hier könnte man Composer-bibliotheken sicher einbinden, während Plugins z.b. den selben aufruf nutzen. Wir könnten dann auch z.b. Platzhalter-PEAR-Bibliotheken einbinden die den eigentlichen Aufruf dann auf Composer routen. Sobald sich 2.0 dann etabliert hat könnte man die Plugins nach und nach von diesen Altlasten befreien, und natürlich auch neue plugins bauen die nur die neue 2.0 API nutzt.

Genauso könnten wir mit dem DB-Layer verfahren - wir halten einfach eine serendipity_db_query Funktion etc. bereit, die dann die Aufrufe an die neuen DB-Layer durchreicht.

Auch beim Event-System könnte man so arbeiten. Mir wäre es wichtig, dass die alten Plugins nicht alle auf einen schlag allesamt nicht mehr lauffähig sind. Was viele Benutzer an s9y immer geschätzt haben war, dass es ein plugin für eine aufgabe gab. Wenn wir jetzt anfangen und da zu sehr zerfasern mit alternativplugins für version X und Y, wobei die dann auch unterschiedlich viel können, das fände ich sehr verwirrend. Zudem sollten die 1.x versionen auch spartacus noch weiter nutzen können, man kann also nicht einfach alle plugins auf einmal aktualisieren und die für 1.x dann nicht mehr nutzbar machen; daher wären Versionsweichen innerhalb der Plugins dann auch angebracht, und auch hier würde man im Laufe der Zeit dann die alte API deprecaten und entfernen.

Ich denke also man kann hier durchaus den Kerncode umstrukturieren, wenn alle Entwickler ein sehr genaues Augenmerk und Konzept dafür haben, wie neue Methoden im Kontext der bestehenden Templates und Plugins implementiert werden, und kompatibel bleiben.

Im einfachsten Falle könnte z.b. serendipity_plugin_api::hook_event() einfach ein fremdes Event-System aufrufen. Wobei man auch hier wirklich prüfen muss ob man hierfür "das Rad neu erfindet" in Form einer Bibliothekseinbindung, obwohl der s9y-Kern derzeit das selbe deutlich performanter und gezielter umsetzt - man muss also auch gezielt überlegen was ein neues Event-System für Vorteile bringen würde, und ob das performancemäßig auch ein Fortschritt ist.

Grüße,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: Roadmap Serendipity 2.0 - Vorschlag

Post by Timbalu »

Rumps! Der Ich-lastige (Unter)Ton gefällt mr darin irgendwie nicht..., :roll: aber anyway:

Ich sehe absolut keinen Grund für einen Merge in den nächsten Wochen. Wozu die Eile?!
Die 2.0 erlaubt noch sehr viel Feinarbeit und die darin enthaltenden "Vorschläge" werden an der einen oder anderen Ecke auch noch mal überdacht werden müssen.

Zur Serendipity Codebasis:
It's ein "best of both" worlds und entwickelt sich.
Zwangsläufig wird Code nach und nach auf PHP5 umgestellt.
Das kann aber langsam und kontinuierlich und mit Augenmaß geschehen.
Zb ist ja mysql_ mit PHP 5.5 deprecated, so dass wir das sowieso auf pdo_ oder so umschwenken müssen. http://php.net/manual/en/migration55.deprecated.php
Wieweit ein anderer DB-Layer wirklich Sinn machen würde - gegenüber all der Arbeit es überall umzustellen - kann ich aus dem Stand nicht beurteilen, ebenso was es mit dem Composer auf sich hat.

Ansonsten ist es doch gerade das Schöne an Serendipity, dass es über ein sehr geniales Pluginsystem - und überhaupt Gesamtkonzept - verfügt. Ich sehe keinen Grund das grundlegend zu ändern und verstehe überhaupt nicht, warum man da ein neues Event-System fordern wollte.
Nur weil man eventuell daran gewöhnt ist, alles vollständig abstrahiert zu haben, muss man das nicht immer auf ein solches System wie Serendipity übertragen. Die Vor und Nachteile heben sich oft gegeneinander auf. Alles andere kann man besprechen und miteinander entwickeln.
Serendipity ist gewachsen, wie ein gut abgehangener Schinken, aber ist nicht zerfleddert oder generell unordentlich geworden, wie so viele andere Projekte die danach zerbrachen, sondern ist in sich rund und stabil. Das ist zu respektieren! Diese Achtung - auch wenn es "nur Software" ist, ist für mich ein wesentlicher Punkt in der gemeinsamen Arbeit und Entwicklung.

Ich finde die angespochenen Punkte sollten wenigstens einzeln erklärt und dann auch besprochen werden. Der eine oder andere Bruch in Serendipity wird sich zwangsläufig nicht vermeiden lassen, wenn man nicht stehenbleibt. Das ist allen bewusst.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
onli
Regular
Posts: 2825
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: Roadmap Serendipity 2.0 - Vorschlag

Post by onli »

Ich bin mit Falks Liste (im Grunde) komplett einverstanden und sehe das wie Garvins letzten Post: Wenn man das richtig macht, muss nicht viel kaputtgehen (und ein bisschen darf in meinen Augen). Einzeln:
Ich möchte die 1.7er und die 2.0er zusammenfügen (am besten bis KW 27)
Wir haben da ja gestern schon gemerkt, dass dabei ein bisschen was kaputt ging und 2.0 im Installer kaputt war. Ist also sehr sinnvoll, das jetzt zu erledigen, bevor man diese großen Dinge angeht.
falk wrote:Danach baue ich Composer-Unterstützung ein
Das war ja diese Abhängigkeitsverwaltung, die für uns die Libs ziehen würde. Das klang für mich super.
falk wrote:Datenbank-Schema-Überarbeitung (mysql)
Da brauchen wir das bestehende ja nicht unbedingt brechen, sondern können mit Indexes und einzelnen Änderungen optimieren. Wenn nicht, ein passender Upgrade-Task -> machbar
falk wrote:Die veralteten PEAR-Bibliotheken werden ausgetauscht (gegen aktuelle oder andere Bibliotheken weiß ich noch nicht).
+1
falk wrote:neuem Datenbank-Layer
Fände ich sehr sinnvoll, man könnte in der bestehenden Api wie von Garvin angemerkt einfach etwas hinterhängen, z.B. das zend\db-ding. Auf einem Schlag wäre da einiges an Arbeit weg und mehr Datenbanken zukunftssicher unterstützt.

Bei den anderen beiden bin ich nicht sicher, Plugins zu brechen würde mir Sorgen machen - andererseits ist das Aufräumen da nötig, auch aus Respekt vor den Nutzern, damit sie sich nicht durch kaputte Plugins kämpfen müssen. Und der Installer ist, naja, funktionabel derzeit. Oder meintest du damit Spartacus?

Insgesamt: Ein Thread pro Projekt und zusammen daran arbeiten, dann wäre das glaube ich jeweils eine gute Sache und ich wäre gerne dabei.
falk
Regular
Posts: 512
Joined: Tue Sep 27, 2005 10:16 am
Location: DD
Contact:

Re: Roadmap Serendipity 2.0 - Vorschlag

Post by falk »

Hallo,

viel Text und gute Antworten. Ich versuche mal eine Zusammenfassung.

mattsches hat mir voll und ganz aus der Seele gesprochen. Ich stand schon so oft vor der Idee, einen Fork von S9y zu beginnen. Es gibt so viele Stellen im Code an denen ich schrauben möchte. Doch immer stelle ich mir Garvin vor wie er mit Adleraugen auf jede Zeile Code schaut und überprüft, ob irgendeine Kompatibilität zu S9y 0.3 gebrochen wurde. Klingt komisch, ist aber so. Aber letztendlich hat mich Maltes E-Mail dazu gebracht, die Kraft doch in S9y zu stecken. Außerdem hat mattsches recht: Eine gute Codebasis ermuntert andere Programmierer eher etwas zu S9y beizutragen. Auch Matthias würde sich freuen, denn wenn irgendwann keine HTML-Sachen im PHP zu finden sind, hat er die Freiheit die er als Template-Designer möchte.

Trotz allem gibt es Spielregeln, die eingehalten werden müssen. Mir ist bspw. aufgefallen, das es keinen Coding-Standard gibt. Da sind wir eigentlich auch schon beim Grundproblem: Wo soll S9y mit der Version 2.0 hin? Und wie erreichen wir dieses Ziel? Was sind die Rahmenbedingungen?

Der Vorteil bei firmenfinanzierten Open-Source-Projekten ist, das dort ein Projekt-Management dahinter steckt. Das hat S9y nicht. Wir sind verstreute Programmierer, die auf S9y einen eigenen Blick werfen. Aber es gibt halt nicht die Tools und Prozesse wie bspw. bei Magento.
Ich merke, es gibt durchaus Interesse an meinen Ideen. Lassen wir sie einfach umsetzen. Wenn sie gut sind, okay. Wenn sie nicht gut sind, schmeißen wir das Zeug weg. Was haben wir verloren? An sonst verweise ich gerne auf meinen Artikel https://www.fadoe.de/blog/archives/398- ... issen.html. Der Wille etwas an S9y zu verbessern ist da. Und ich nehme gerne BC-Breaks in Kauf wenn anschließend der Code besser wartbar ist. Für mich ist das Ganze eine Übung des Refactorings. Und ich freue mich über jede Zeile veralteten PHP-Code, die verschwindet.

Den Merge möchte ich bis nächste Woche soweit fertig haben, damit wir eine Basis haben, an der wir weiter arbeiten können. Je länger wir warten und je mehr Änderungen in die aktuelle 1.7 einfließen, um so ekliger wird das Mergen. Das merke ich jetzt schon, weil es sich im Prinzip schon um zwei Software-Versionen handelt. Merged mal Joomla und Mambo zu sammen ...
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Roadmap Serendipity 2.0 - Vorschlag

Post by yellowled »

falk wrote:Auch Matthias würde sich freuen, denn wenn irgendwann keine HTML-Sachen im PHP zu finden sind, hat er die Freiheit die er als Template-Designer möchte.
Hm, jein.

Erstens sollte es dabei nicht um mich gehen – ich bin schon lange kaum noch Template-Designer, ich sehe mich eher als Kern-Frontendler. Dennoch fände ich persönlich es schon gut, wenn jedes Stück Markup, das s9y ausgibt (sei es in Back- oder Frontend) smartifiziert wäre – wenn das in Sachen BC und Performance vertretbar ist. Die Entwicklung des 2.0-Backends wäre ohne Smarty nicht halb so weit.

Andererseits gibt es genug Leute, die genau das (Smarty) an s9y abschreckt. Das bedeutet nicht, dass ich Smarty zur Diskussion stellen oder die Trennung von Markup und Funktionalität abwerten will, ich sage nur, dass es nicht das Wichtigste ist.
falk wrote:Wenn sie nicht gut sind, schmeißen wir das Zeug weg.
Wenn wir damit auch das 2.0-Backend wegschmeißen würden, würde ich allerdings ein klitzekleines bisschen ungehalten. :wink:
falk wrote:Je länger wir warten und je mehr Änderungen in die aktuelle 1.7 einfließen, um so ekliger wird das Mergen.
Im master dürften im Vergleich zu 1.7 im Moment relativ wenig Änderungen sein. Die Änderungen stecken im 2.0-branch.

YL
Post Reply