Hi Christian, *, also gut, Tüte holen reinatmen runtertunen.. :o))
Christian Lohmaier schrieb: >2010/11/5 Friedrich Strohmaier <damokles4-lis...@bits-fritz.de>: >> Christian Lohmaier schrieb: >>>2010/11/5 Friedrich Strohmaier <damokles4-lis...@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+h...@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
