Re: [de-discuss] [Box] Seitenstruktur für die Entwicklungswerkstatt http://devel.libreofficebox.net/

Hi Christian, *,

also gut, Tüte holen reinatmen runtertunen.. :o))

Christian Lohmaier schrieb:
> 2010/11/5 Friedrich Strohmaier <damokles4-listen@bits-fritz.de>:
> > Christian Lohmaier schrieb:
> > > 2010/11/5 Friedrich Strohmaier <damokles4-listen@bits-fritz.de>:

[...]

> > > > > Wozu das server-Verzeichnis listing? Welcher Zweck steht dahinter?

> > [...]

> > > Hmm. k.a. was man damit debuggen sollte...

> > unwichtig - *ich will es haben!* :o))

> OK, "überzeugt" :-) - der, der schafft bestimmt :-)
> Ich wäre ja schön blöd, wenn ich irgendwem seinen Arbeitsablauf
> zerstören würde :-)

na eben, sonst kannste den Kram auch noch machen.. :o))

> > > > http://devel.prooo-box.org/de/misc/versionsverwaltung/

> > > Naja, aber das muß ja nicht alles unter devel.libreofficebox liegen,
> > > oder?

> > Du hast recht - nicht *Alles*! aber alles, was weder zum Endprodukt
> > noch auf die Homepage soll, sondern Werkzeug ist für gute Arbeit -
> > Werkstatt - devel.

> Ah, OK, dann ist hier schon das erste Mißverständnis - ich dachte
> devel ist das, was im Endprodukt landen soll, aber naturgemäß erst zur
> nächsten Version.

stimmt natürlich auch..

> Sprich snapshot von devel = release, release ist dann statisch, kann
> auch als "live.libreofficebox" dienen und an devel wird an dem
> nächsten Release gearbeitet.

Das darf auch gerne flexibel sein und bei Bedarf umgeschaltet werden
können. Prinzipiell gibt es für live zwei Szenarien:

1. Es wird ein Abzug des letzten Releases im Netz vorgehalten - statisch
2. Es wird der aktuelle Arbeitsstand gezeigt - also ein Abzug von den
devel Inhalten.

Beide Szenarien haben gute Gründe für und wider. Wir hatten bisher
Variante 2  man sieht, wie es "lebt".

Warum nun live, wenn Variante 2 zum Zuge kommt? Der gemeine
downloadwillige Besucher hat bisher immer wieder die live-seite der Box
genutzt, um sich mit der besten aller Office-Suiten oder beliebter
Zusätze zu versorgen, weil alles so schön beisammen ist. Besonders die
Mac-User liebten diesen Weg aber auch die free-bsds beschritten ihn
gerne. Wir konnten ohne das traffic-limit zu sprengen diese Wünsche
efüllen indem ich per .htaccess dafür sorgte, dass die beliebtesten
Stücke unbemerkt bei einem Mirror mit dickem Datenschlauch geholt
wurden. Diese Technik wiederum ist Gift für Tester, die Links testen
wollen oder ein neues Paket einspielen und immer wieder das Alte
angeboten bekommen oder Schlimmeres.

Dafür dann devel. Hier sorge ich per robots.txt dass seriöse
Suchmaschinen von der Listung absehen und somit die
Direktdownloadmöglichkeit nicht über Gebühr strapaziert wird.

Nun weiter:
Bisher war jetzt in devel/DVD z.B. der Inhalt so zu sehen, wie er
nachher in das ISO eingebaut wurde 1:1. Jetzt kommt mit dem CMS eine
weitere Instanz dazu, die den Inhalt verwaltet. Das was in das ISO kommt
wird aus diesen Inhalten extrahiert zu einem statischen Abbild
umgewandelt. *Erst dieses* wird dann in das ISO eingebaut. Ich will auch
bei diesem Zwischenschritt alle Elemente möglichst ungehindert anschauen
können, denn da ist 1:1 drin, was nachher im ISO sein sollte.  Nachdem
unser aller Objekt der Begierde ein *Open*source Produkt ist, will ich
dieses Privileg nicht für mich behalten - ich könnte es ja auf dem
Server anschauen -, sondern allen zugänglich machen, die daran Interesse
haben. Es soll also weiterhin ein Verzeichnis geben in dem die
DVD-Inhalte in der Reinform zu betrachten *und zu untersuchen* sind.

Das gilt natürlich auch für andere Dinge, die für irgendwelche Menschen
da draußen interessant sein könnten und die nicht im CMS erzeugt
werden..

> > > und wenn es um einfache Auflistung von Inhalten aus einem
> > > Verzeichnis geht kann man ja auch einen entsprechenden Seitentyp
> > > erstellen/verwenden.

> > nein! Nicht im CMS! Einfach Webspace - Link sehen - gut is.

> Ob der Apache ein Verzeichnislisting erstellt oder das cms macht in
> meinen Augen keinen großen Unterschied.

Doch, wenn das CMS das machen soll in Bereichen wo es nicht beikommt
wird es - äh - interessant.

> > > (man kann auf alles direkt verweisen, was tatsächlich als Datei
> > > existiert, falls nicht durch eine entsprechende htaccess verboten) -
> > > z.B. http://devel.libreofficebox.org/legacydatetimefields/LICENSE
> > > Aber das heißt noch lange nicht, daß es sinn macht, die Inhalte auf
> > > dem Server auch im cms-Verzeichnis zu haben.

> > Eben! Bitte nicht diskutieren.

> Naja, eben doch diskutieren. Wenn es darum geht Zeug ins
> cms-Verzeichnis zu schaufeln, nur damit man es per URL erreichen kann
> ist das der falsche Weg.

Ich wollte dir rechtgeben: Ich will die sachen *nicht* im
CMS-Verzeichnis haben! - Aber sehr wohl in der Subdomain devel!!

> Also Fakt (so wie ich es sehe), das Zeug, zumindest die automatisch
> generierten Sachen wie das Beispiel mit den versionslisten braucht
> nicht im cms-Verzeichnis zu liegen.

genau!

> Andere Sachen, wie ein Verzeichnislisting vom mozilla-installer o.ä.
> liegen ja schon drin (in assets), also machts da keinen Sinn das
> woandershin zu packen.

s.o. Das CMS ist *ein* aber nicht *der einzige* Produktionsschritt.

> > Ich will unter devel ohne Umweg zugänglichen Webspace haben von innen
> > und außen - punkt.

> zugänglicher Webspace ist ziemlich schwammig. Du willst die Dateien in
> assets sehen, per apache-Verzeichnis listing.

Nein, ich will andere Verzeichnisse in devel haben, in denen ich ohne
CMS schalten und walten kann.

> > > Naja, ist halt essentiell für das Verständnis der Zusammenhänge :-)

besser jetzt? :o))

> > Ich hätte es schon längst umgesetzt, wenn mir nicht sstrp einen
> > Strich durch die Rechnung gemacht hätte. Dann wäre die Stunde
> > Mailschreiben für was anderes frei gewesen. :o))

> Nee, aber dan wüßte wieder keiner was wann wohin gesichert werden muß,
> etc.

Diese Dinge wussten auch schon bisher nur wenige aber auch genau dann,
wenn es mehr werden, will ich nicht anfangen erklären zu müssen, was man
tun muss, um das CMS auszutricksen.

> > Was hältst Du davon, für das CMS eine eigene Subdomain zu machen
> > z.B. cms.libreofficebox.org?

> Ist kein Problem. Aber wie auch bei den anderen Lösungen: Es würde
> wirklich helfen, das "warum" zu kennen. auch cms.libreoffice.org würde
> aus demselben Verzeichnis auf dem Server bedient,

Ja, aber es wäre nicht mehr das Verzeichnis in dem die Subdomain devel
liegt und ich oder wer auch immer könnte bereits mit bescheidenen
Linuxkenntnissen darin rumwerkeln.

> also glaub ich nicht, daß es das ist, weshalb Du es vorschlägst.

Du hast natürlich recht: Das Schlüsselproblem ist die Tatsache, dass das
CMS das DocumentRoot in seinem Verzeichnis haben will, und ich nicht
weiß, ob und wenn wie ich ihm dieses abgewöhnen kann. Hätte ich es
gewusst hätten wir viel Zeit gespart und ich hätte heute statt Mails
geschrieben z.B. die Verzeichnisstruktur für die Medieninhalte
vorbereiten und die Scripte anpassen können. Morgen ist die Zeit wieder
für andere Dinge reserviert und es wird wieder knapp, knapp.

> Und da wären wir wieder bei dem Problem der Frage nach dem Weg, und
> nicht der Beschreibung des Ziels/Zwecks.

eigentlich war mir heute nicht nach philosophieren sondern nach
arbeiten.

> > Es wird ja zumindest noch für die eigentliche Homepage zuständig
> > sein - also libreofficebox.org und könnte dann mit dem
> > entsprechenden Aufruf umgeschrieben werden für devel oder
> > Hauptdomain.

> Ich weiß, es kostet Zeit es zu erklären, aber trotzdem..

> es gibt (so wie ich es sehe)
> live.* - da landet ein snapshot des aktuellen releases, eine statische
> Kopie an der nix mehr modifiziert wird (bzw. nur in seltenen
> Ausnahmefällen)
> devel.* - da wird an der nächsten Version, am nächsten Release
> geschraubt, wenn es fertig ist, wird davon der snapshot erstellt der
> dann auf live.* endet
> [www.]* - Einstiegsseite mit allgemeinen Informationen und links zum
> Downlod des Isos wie auch Verweise auf die live-Seite, Informationen
> für Helfer u.ä.

> Soweit richtig?

Soweit richtig. Mehr Details oben beschrieben.

> dann kann man devel und www. in silverstripe verwalten, in einer
> instanz, in einem physikalischen cms Verzeichnis (Webseiteninhalt ist
> ja wiegesagt in der Datenbank, im Verzeichnis sind die assets, ggf.
> ein cache mit statischen HTML und die Dateien von silverstripe selbst)

Auch oben beschrieben: Das CMS ist nur ein Teil des
Produktionsprozesses. Da sind noch weitere außerhalb desselben.. 

> live ist komplett statisch, bei notwendig werdenden Änderungen werden
> die HTML-Dateien direkt auf dem Server ausgebessert.

Darf gerne flexibel sein (und ggf die Ergebnisse von devel-CMS
spiegeln).

> Für die devel.* soll es nun
> * ein apache-Verzeichnislisting der Dateien in assets geben

wenn es der Sache dient - das ist nicht, wovon ich spreche.. :o))

> (würde in dem Fall, daß www auch davon verwaltet wird auch die
> Dateien von www zeigen, bzw. man müßte halt entsprechende Unterordner
> in assets anlegen/man erstellt symlinks in einem anderen Verzeichnis)

Nein. assets/ ist mir eigentlich egal..

> * über devel.libreofficebox.org/irgendeineurl soll ein
> "Versionsverzeichnis" erreichbar sein

genauer: ein Verzeichnis in dem unabhängig vom CMS Inhalte eingestellt
und abgerufen werden können.

> * [bitte mit weiteren Anforderungen ergänzen]

das war's schon.

Ich weiß zwar, dass ich leicht Missverständnisse füttern kann - heute
scheine ich aber besonders gut in Form zu sein. ;o)).

> Dann wird das schon noch was..

Ich bin gespannt, wieviel Gesprächsbedarf noch entsteht für ein simples,
vom CMS unabhangiges Verzeichnis innerhalb derselben Subdomain.. ;o))


Gruß
-- 
Friedrich
Libreoffice-Box (http://devel.libreofficebox.net/)
.. und nicht vergessen: Flüster's den Listen! :o))
Schöne Grüße von der Sonnenalb



-- 
E-Mail to discuss+help@de.libreoffice.org for instructions on how to unsubscribe
List archives are available at http://de.libreoffice.org/lists/discuss/
All messages you send to this list will be publicly archived and cannot be deleted