Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.