Datei-Struktur

[Chris M.]

Ich bin ja gerade dabei die Dateien etwas zu sortieren und würde dabei noch etwas Input benötigen.

Vorab: Design-Ziele sind:

• Das SVN muss so wie's ist lauffähig sein (d.h. den visu-Ordner auf's WireGate nach /var/www auschecken und einfach von dort laufen lassen)
• Dafür darf das SVN gewisse Performance-Einschränkungen haben (wie z.B. keine Minimized-Versionen und viele kleine Dateien)
• Ein Skript (z.Zt. Makefile) soll im ersten Schritt das in eine Ziel-Struktur umbauen wie z.B. Dateien zusammenfassen (d.h. noch gut debugbar)
• In einem weiteren Schritt das ganze optimieren (-> Minimizen)
• Als letzten (optionalen) Schritt erleichtern ein fertiges Release daraus zu backen, dass zu den SF-Files hochgeladen werden kann
• Und natürlich: eine für's Entwickeln optimale Struktur schaffen

Zumindest letzteres sind wir inzwischen einen guten Schritt näher, da jetzt jedes Widget in einer eigenen Datei lebt.


Aber ich frage mich z.Zt. Dinge wie:

• Sollen die Plugins umziehen nach /structure/pure?
  (Langfrist-Ziel ist, dass "einfache" Widgets und Plugins erst mal gleichberechtigt sind und nur durch eine Config-Option im Makefile eingebunden (= Widget) oder optional (= Plugin) werden)
• Ist /dependencies/ ein passender Name - oder wäre /external/ besser?
  (Durch's abtrennen vom CV eigenen Source kann man besser eine automatisierte Doku erstellen, zumindest YUIDoc geht halt nur Verzeichnisweise)
• Wie und wo sollen die generierten Dateien leben?
  Z.B. die index.html muss ja automatisiert angepasst werden (macht das aktuelle Makefile schon) - aber wo und wie soll die hin? Überschreiben geht nicht, da ich sonst einen SVN Konflikt bekomme...
  => Ein paralleles /release/ Verzeichnis?
  • Wenn parallel: mit kompletter Kopie der sonstigen Struktur?
    (+ passende svn:ignore gegen Nebenwirkungen)
  
  

Auch wenn das die drängendsten Fragen sind (und ich dort Input erhoffe), wäre spannend auch noch:

• Welchen Minimizer nehmen?
• Welches Doc-Tool? (z.Zt. verwende ich YUIDoc)

[makki]

Gute Fragen die ich nicht unbeantwortet lassen will - aber lieber erstmal drüber schlafen(!)

Ob man nicht, wenn man schon radikal ändert, hergeht und sich den FHS nochmal scharf durchliest und es dann gleich wirklich "richtig" macht (nominell hat nichts ausführbares was in /var/www zu suchen, ist halt anstregend..)
Und das KNX-Backend stand heute nur Bestandteil eines Hacks, wenns nicht upstream wird muss es eben in die CV als Client/Backend (daher meine Anspielung auf AC/AM keine Angst, so schlimm finde ich das [heute!] nicht mehr, wär ja schön wenn wenigstens für kenner&könner das alles auch komplett auf anderen Plattformen geht..)

Makki

[Chris M.]

Klar, wenn der FHS da was fordert, dann sollten wir das umsetzen.
Da die CV, vom Backend abgesehen, keine "ausführbaren" Dateien hat darf die IMHO schon im normalen Web-Root liegen.

Da die CV von der Backend-Implementierung (insb. ob's ein KNX dahinter ist) unabhängig ist, gehören die CGIs dort eigentlich nicht rein. (In's allgemeine OpenAutomation SVN dagegen gerne).

[makki]

Klar, wenn der FHS da was fordert, dann sollten wir das umsetzen.

Wir sollten drüber nachdenken, mehr müssen wir nicht, weil es macht die Sache auch unübersichtlicher und anstrengender..

Da die CV, vom Backend abgesehen, keine "ausführbaren" Dateien hat darf die IMHO schon im normalen Web-Root liegen.

Hmm, jedes PHP in Editor und Widget ist was ausführbares-wiegesagt ich sehe das nicht mit Prio; für sagen wir mal bis 0.99 ist es mir lieber wir machen die "einfache Nummer" (das z.B. das PHP zum Widget da liegt..), wir sollten nur ab und an dran denken das es so nicht 100% stimmt..

Da die CV von der Backend-Implementierung (insb. ob's ein KNX dahinter ist) unabhängig ist, gehören die CGIs dort eigentlich nicht rein.

Stimmt eigentlich, ich pflege nur defacto gerade einen eibd-Fork, was ich nicht will! also gehören die beiden buben entweder in ein sep. Packerl oder soweit gefixed, das mkoegler sie aufnimmt (-> Stups? wer machts?)
Für mich funktionierts ansonsten ja, sorry, kein need..

Makki

[Chris M.]

Stimmt eigentlich, ich pflege nur defacto gerade einen eibd-Fork, was ich nicht will! also gehören die beiden buben entweder in ein sep. Packerl oder soweit gefixed, das mkoegler sie aufnimmt (-> Stups? wer machts?)
Für mich funktionierts ansonsten ja, sorry, kein need..

Check es mal nach /tools/ oder so ein, ich würde gerne mal drüber schauen, da ich immer wieder mal den Effekt habe, dass "r" und eibd je 50% CPU brauchen und alles hängt...

[makki]

Meine (ganzen) kleinen Hacks liegen momentan hier, so auch dieser..
(Wenn ich mir den Code ansehe wird mir gleich übel aber es hat aktuell halt keine Prio für mich, das ohne Not aufzuhübschen solange es funktioniert..)

Makki

[Chris M.]

Ich bin ja gerade dabei die Dateien etwas zu sortieren und würde dabei noch etwas Input benötigen.
[...]
Aber ich frage mich z.Zt. Dinge wie:

• Wie und wo sollen die generierten Dateien leben?
  Z.B. die index.html muss ja automatisiert angepasst werden (macht das aktuelle Makefile schon) - aber wo und wie soll die hin? Überschreiben geht nicht, da ich sonst einen SVN Konflikt bekomme...
  => Ein paralleles /release/ Verzeichnis?
  • Wenn parallel: mit kompletter Kopie der sonstigen Struktur?
    (+ passende svn:ignore gegen Nebenwirkungen)
  
  

Ich habe das jetzt mal mit /release/ so umgesetzt.

Auch wenn der Minimizer noch nicht drinnen ist, sollten wir nun wieder eine stabile Grundlage haben, auf der an allen Seiten wieder weiter entwickelt werden kann. Der Rest sollte dann unter laufender Entwicklung ohne Nebenwirkungen eingebaut werden können.