Daseinsberechtigung von Server Sides Include?

[Julius]

Hallo an alle :-)

SSIs scheinen ja ein Schattendasein zu führen (meist im Schatten von PHP) und daher frage ich mich dann doch, warum die (wann?) überhaupt eingeführt wurden. Folgende Theorien habe ich bereits:

1. PHP und SSI sind beide so 1995-1999 entstanden und der Masse der „Webmaster“ bekannt geworden – es war nicht klar, wer bei Software-Unterstützung, Feature-Reichtum und Akzeptanz gewinnen würde. Dieser Artikel in der apacheweek stützt das zumindest von der Zeit her.
2. SSI lässt sich leichter auf Shared-Hostern einsetzen, bzw. im Vergleich zu PHP.

Was meint ihr dazu?

Gruß
Julius

[JürgenB]

Hallo,

mir hat vor Jahren unser Serveradministrator mal gesagt, das der Aufwand für das Parsen und ausliefern einer SSI-Seite etwa doppelt so groß ist, wie das Ausliefern einer reinen html-Seite. Bei php war der Aufwand etwa zehnmal so groß.

Gruß
Jürgen

[Julius]

Hallo JürgenB,

mir hat vor Jahren unser Serveradministrator mal gesagt, das der Aufwand für das Parsen und ausliefern einer SSI-Seite etwa doppelt so groß ist, wie das Ausliefern einer reinen html-Seite. Bei php war der Aufwand etwa zehnmal so groß.

Interessanter Ansatz, das müsste man mal in einer kontrollierten Umgebung ausprobieren.

Mir ist noch eine vierte Theorie in den Sinn gekommen: Sowohl PHP (damals noch Personal Home Page Tools) als auch SSI hatten beide zum Ziel, einfache Probleme einer „Homepage“ wie das Ausgeben des Datums der letzten Änderung lösen zu können, ohne gleich irgendwelche CGI-Programme in C oder Perl erstellen zu müssen.

Gruß
Julius

[pl]

Der Webserver wird angewiesen, das Dokument vor der Auslieferung zu parsen, ggf. Scriptinterpreter oder weitere Prozesse zu starten und deren Ergebnisse in das Dokument einzubauen: Schlecht für die Performance, da läuft ein reiner CGI-Prozess performanter, weil der Interpreter nur einmal gestartet wird.

HTML ist mit Script Code bunt gemischt. Auch nicht schön. Rational und logisch gedacht kann sowas keine Zukunft haben.

[Gunnar Bittersmann]

@@pl

Der Webserver wird angewiesen, das Dokument vor der Auslieferung zu parsen, ggf. Scriptinterpreter oder weitere Prozesse zu starten und deren Ergebnisse in das Dokument einzubauen: Schlecht für die Performance

SSI sind wohl kaum der Flaschenhals.

HTML ist mit Script Code bunt gemischt. Auch nicht schön.

Bei SSI kann man wohl kaum von Script sprechen. Und HTML ist mit Code auch bei PHP und bei Template-Engines „bunt gemischt“. Und das ist auch gut so.

Rational und logisch gedacht kann sowas keine Zukunft haben.

Das war wohl mal wieder ein echter Hotti. Fernab von jeglicher Rationalität und Logik.

LLAP 🖖

[Julius]

Hallo Gunnar,

HTML ist mit Script Code bunt gemischt. Auch nicht schön.

Bei SSI kann man wohl kaum von Script sprechen.

Sondern eher eine Art Shortcut für Dinge, die man sonst zur Zeit der Einführung von SSI mit einem dedizierten CGI-Skript erschlagen hätte?

Gruß
Julius

[pl]

HTML ist mit Script Code bunt gemischt. Auch nicht schön.

Bei SSI kann man wohl kaum von Script sprechen.

Sondern eher eine Art Shortcut für Dinge, die man sonst zur Zeit der Einführung von SSI mit einem dedizierten CGI-Skript erschlagen hätte?

SSI ermöglicht das Einbinden von externen Scripts und das Rendern der Rückgabewerte ins Dokument. Da auf diese Art und Weise mehrere Scriptinterpreter gestartet werden können, ist das sehr ineffizient.

[Julius]

Hallo pl,

Bei SSI kann man wohl kaum von Script sprechen.

Sondern eher eine Art Shortcut für Dinge, die man sonst zur Zeit der Einführung von SSI mit einem dedizierten CGI-Skript erschlagen hätte?

SSI ermöglicht das Einbinden von externen Scripts und das Rendern der Rückgabewerte ins Dokument.

PHP, Perl und Python aber auch – dass es eine Möglichkeit gibt, heißt noch lange nicht, dass man sie auch nutzen musst. Genauso könntest du deine Smartwatch Bitcoins „minen“ lassen, was aber natürlich wenig Sinn macht.

Ich könnte mir vorstellen, dass SSI sehr effizient ist, wenn es darum geht, bestimmte Informationen in ein sonst komplett fertiges Dokument einzufügen, beispielsweise das Datum der Letzten Änderung oder einen Spruch des Tages auszugeben.

Gruß
Julius

[pl]

hi,

Ich könnte mir vorstellen, dass SSI sehr effizient ist, wenn es darum geht, bestimmte Informationen in ein sonst komplett fertiges Dokument einzufügen, beispielsweise das Datum der Letzten Änderung oder einen Spruch des Tages auszugeben.

Du meinst Prozesse, die nur im Webserver laufen, sozusagen native SSI. Das ist sicher effizient, aber eben sehr eingeschränkt. Dagegen gibt es Entwicklungen, die auch in diese Richung gehen aber viel universeller sind: mod_perl und natürlich auch mod_PHP. Im Prinzip wird ein Code bereits beim Starten des Webservers kompiliert.

Sei es der Code einer Klasse und bei jedem Request wird eine Instanz gebildet. So hat diese Instanz einen höchst performanten und wahlfreien Zugriff auf Datenstrukturen, die seit dem Starten des Webservers im Hauptspeicher liegen. Dann brauchst Du nur noch einen kleinen Templateprozess, der diese Variablen ins Template rendert.

Wobei der Code der Templateengine auch schon beim Starten des Webserves kompiliert werden kann. Im Gegensatz zu SSI unbegrenzte Möglichkeiten. Tatsächlich kenne ich niemand der SSI einsetzt, höchstens mal damit gespielt hat.

Schöne Grüße.

[Matthias Apsel]

Hallo pl,

Tatsächlich kenne ich niemand der SSI einsetzt, höchstens mal damit gespielt hat.

Was unter anderem an dem geringen Befehlsumfang von SSI liegt. Ich hatte relativ lange SSI produktiv im Einsatz.

Bis demnächst
Matthias

[JürgenB]

Hallo

… Tatsächlich kenne ich niemand der SSI einsetzt, höchstens mal damit gespielt hat.

als wir in der Uni noch kein CMS hatten, habe ich auf allen meinen Seiten SSI eingesetzt. Und auch heute werden einige dynamische Inhalte per SSI eingebunden.

Gruß
Jürgen

[Julius]

Hallo pl,

Du meinst Prozesse, die nur im Webserver laufen, sozusagen native SSI.

Ich glaube, du vertust dich mit dem Begriff „Includes“ – da geht es nicht nur um das Einbinden von CGIs sondern auch das Ausgeben von (Umgebungs-)Variablen und anderen Dateien.

Das ist sicher effizient, aber eben sehr eingeschränkt. Dagegen gibt es Entwicklungen, die auch in diese Richung gehen aber viel universeller sind: mod_perl und natürlich auch mod_PHP. Im Prinzip wird ein Code bereits beim Starten des Webservers kompiliert.

Darauf wollte ich im Prinzip die ganze Zeit hinaus: SSI ist sehr eingeschränkt – warum wurde es eingeführt? Eine meiner möglichen Ansätze war daher, dass es etwa zeitgleich mit PHP entstanden ist.

Gruß
Julius

[Christian Kruse]

Hallo Julius,

Darauf wollte ich im Prinzip die ganze Zeit hinaus: SSI ist sehr eingeschränkt – warum wurde es eingeführt? Eine meiner möglichen Ansätze war daher, dass es etwa zeitgleich mit PHP entstanden ist.

SSI ist entstanden, als man Server-seitige Programmierung mit Perl oder C gemacht hat. Für vieles war Perl ein Overkill, von C will ich gar nicht erst sprechen. Deshalb hat man SSI entwickelt. PHP war damals weder bekannt noch verbreitet, das kam erst später.

LG,
CK

[Julius]

Hallo Christian,

Darauf wollte ich im Prinzip die ganze Zeit hinaus: SSI ist sehr eingeschränkt – warum wurde es eingeführt? Eine meiner möglichen Ansätze war daher, dass es etwa zeitgleich mit PHP entstanden ist.

SSI ist entstanden, als man Server-seitige Programmierung mit Perl oder C gemacht hat. Für vieles war Perl ein Overkill, von C will ich gar nicht erst sprechen. Deshalb hat man SSI entwickelt. PHP war damals weder bekannt noch verbreitet, das kam erst später.

Also wieder mal eine Technik, die früher mal Probleme gelöst hat und heute selbst ein potentielles Problem ist.

Ich werde das in die SSI-Artikel in der Doku einarbeiten und die PHP-Sektion aufmöbeln. Es ist schon bezeichnend, dass SSI ausführlicher erklärt wird, als die Grundlagen von PHP.

Gruß
Julius

[Matthias Apsel]

Hallo Julius,

Also wieder mal eine Technik, die früher mal Probleme gelöst hat und heute selbst ein potentielles Problem ist.

Die Entwicklung schreitet voran.

Ich werde das in die SSI-Artikel in der Doku einarbeiten und die PHP-Sektion aufmöbeln.

Ich weiß nicht, ob es wirklich sinnvoll ist, eine PHP-Dokumentation aufzubauen. Allerdings sind die Seiten, die die Grundlagen der Programmierung am Beispiel von PHP erklären (sollen!) schon beinahe peinlich. „Hinweis: Achten Sie darauf, Endlosschleifen zu vermeiden!“

Es ist schon bezeichnend, dass SSI ausführlicher erklärt wird, als die Grundlagen von PHP.

Der SSI-Artikel ist eine Übernahme aus der alten Doku, in der es PHP überhaupt nicht gab.

Bis demnächst
Matthias

[Julius]

Hallo Matthias,

Ich weiß nicht, ob es wirklich sinnvoll ist, eine PHP-Dokumentation aufzubauen. Allerdings sind die Seiten, die die Grundlagen der Programmierung am Beispiel von PHP erklären (sollen!) schon beinahe peinlich. „Hinweis: Achten Sie darauf, Endlosschleifen zu vermeiden!“

Wieso genau? Hättest du da lieber ein Beispiel?

Gruß
Julius

[Matthias Apsel]

Hallo Julius,

Allerdings sind die Seiten, die die Grundlagen der Programmierung am Beispiel von PHP erklären (sollen!) schon beinahe peinlich. „Hinweis: Achten Sie darauf, Endlosschleifen zu vermeiden!“

Wieso genau? Hättest du da lieber ein Beispiel?

Wie hilft einem Anfänger „Achten Sie darauf, Endlosschleifen zu vermeiden!“, wenn er vielleicht gar nicht weiß, was Endlosschleifen sind? Und nein: while (true) do something; ist in meinen Augen kein Beispiel.

Bis demnächst
Matthias

[Julius]

Hallo Matthias,

Allerdings sind die Seiten, die die Grundlagen der Programmierung am Beispiel von PHP erklären (sollen!) schon beinahe peinlich. „Hinweis: Achten Sie darauf, Endlosschleifen zu vermeiden!“

Wieso genau? Hättest du da lieber ein Beispiel?

Wie hilft einem Anfänger „Achten Sie darauf, Endlosschleifen zu vermeiden!“, wenn er vielleicht gar nicht weiß, was Endlosschleifen sind? Und nein: while (true) do something; ist in meinen Augen kein Beispiel.

Ah, verstehe, also lieber:

$count = 1;
while($count < 4)
{
  echo 'Blabla';
}

... versehen mit der Erklärung, dass die Abbruchbedingung (Variable count >= 4) ja niemals erreicht werden kann, die Schleife also endlos läuft, bis irgendein Timeout greift?!

Gruß
Julius

[Matthias Apsel]

Hallo Julius,

Ah, verstehe, also lieber:

$count = 1;
while($count < 4)
{
  echo 'Blabla';
}

... versehen mit der Erklärung, dass die Abbruchbedingung (Variable count >= 4) ja niemals erreicht werden kann, die Schleife also endlos läuft, bis irgendein Timeout greift?!

zum Beispiel.

Bis demnächst
Matthias

[JürgenB]

Hallo

Ah, verstehe, also lieber:

$count = 1;
while($count < 4)
{
  echo 'Blabla';
}

... versehen mit der Erklärung, dass die Abbruchbedingung (Variable count >= 4) ja niemals erreicht werden kann, die Schleife also endlos läuft, bis irgendein Timeout greift?!

zum Beispiel.

oder der „Klasiker“

for(i=0;i<100;j++) { … };

Gruß
Jürgen

[Julius]

Hallo Matthias,

Ich weiß nicht, ob es wirklich sinnvoll ist, eine PHP-Dokumentation aufzubauen.

Nennen wir es mal lieber „Einführung“. Die von schattenbaum.net ist zwar ganz nett, aber leider nicht unter einer freien Lizenz verfügbar (und diese Ü in den Beispielen sind spätestens seit UTF-8 nicht mehr zeitgemäß).

Gruß
Julius

[Christian Kruse]

Hallo Julius,

Also wieder mal eine Technik, die früher mal Probleme gelöst hat und heute selbst ein potentielles Problem ist.

Naja, das gilt ja für die meisten Techniken. Erst das beste seit geschnitten Brot, dann „considered harmful.“ Früher hat die Mehrheit z.B. Perl toll gefunden, heute spricht man von einer write-only language.

LG,
CK

[pl]

Bei SSI kann man wohl kaum von Script sprechen. Und HTML ist mit Code auch bei PHP und bei Template-Engines „bunt gemischt“. Und das ist auch gut so.

Dann hast Du wohl den Sinn eines Templatesystems nicht richtig verstanden, die Trennung von Code und Layout. Damit wir uns richtig verstehen, ich mache dir das nicht zum Vorwurf. Ich als Rentner darf jedoch gerne mal einen Blick zurückwerfen auf ganz grässliche Dinge, die da draußen im produktiven Umfeld passieren.

So kenne ich z.B. einen Unternehmer der gleichzeitig Programmierer ist. Diese Symbiose ist schonmal fatal. Schlimmer noch ist, dass er an seinem Embed-Perl festhält, was sowohl ein strukturiertes als auch objektorientiertes Programmieren unmöglich macht. Den Code sieht ja auch entsprechend chaotisch aus. So richtig dumm ists, dass sich sowas auch bis hin zum Kunden auswirkt.

Und das Allerschlimmste ist, dass dieser Schurke denkt, er kann das mit Praktikanten, Lohndumping und Scheinbeschäftigungen ausgleichen.

So, jetzt darfst Du lieber Gunni deinen senf dazugeben. Ich hoffe, du hast verstanden, daas es hierbei um wirtschaftliche Dinge geht und nicht um Endlospapier mit geschweiften Klammern drauf.

PS: Auch in der Bibel geht es nur ums Geld. Deswegen heißt es ja auch Testament.

[Der Martin]

Hallo,

SSIs scheinen ja ein Schattendasein zu führen (meist im Schatten von PHP) und daher frage ich mich dann doch, warum die (wann?) überhaupt eingeführt wurden. [...]

Was meint ihr dazu?

wie sinnvoll ist die Frage überhaupt - angesichts der Tatsache, dass hier im Forum in letzter Zeit schon mehrmals von der Verwendung von SSI abgeraten wurde, weil es von manchen Hostern inzwischen nicht mehr angeboten wird?

So long,
 Martin

[Julius]

Hallo Martin,

SSIs scheinen ja ein Schattendasein zu führen (meist im Schatten von PHP) und daher frage ich mich dann doch, warum die (wann?) überhaupt eingeführt wurden. [...]

Was meint ihr dazu?

wie sinnvoll ist die Frage überhaupt - angesichts der Tatsache, dass hier im Forum in letzter Zeit schon mehrmals von der Verwendung von SSI abgeraten wurde, weil es von manchen Hostern inzwischen nicht mehr angeboten wird?

Vorab muss ich dazu vielleicht noch ergänzen, dass es mir nicht unbedingt nur um die Gegenwart sondern auch um die Vergangenheit geht. Ich kann zwar kein genaues Datum finden, aber SSI und PHP schienen beide ursprünglich relativ zeitgleich ein mehr oder weniger minimalistisches Paket von Lösungen für häufige Probleme geboten zu haben. Ab etwa 2000 – 2003 scheint PHP sich ja sehr stark ausgebreitet haben und SSI und Perl als wichtigste Serverseitige Techniken verdrängt zu haben – vielleicht stecke aber ich auch in einer PHP-Filterblase, aber PHP scheint (auch hier) wesentlich öfter thematisiert zu werden als der Rest.
Mittlerweile ist PHP klar die bessere Wahl als SSI, aber früher muss das anders gewesen sein, sonst hätten wir nicht SSI.

Was mich in diesem Zusammenhang stutzig macht, ist die Tatsache, dass es unter dem Tag ssi im Zeitraum 2000 – 2015 keine Einträge gibt?!

Gruß
Julius

[Der Martin]

Hallo,

wie sinnvoll ist die Frage überhaupt - angesichts der Tatsache, dass hier im Forum in letzter Zeit schon mehrmals von der Verwendung von SSI abgeraten wurde, weil es von manchen Hostern inzwischen nicht mehr angeboten wird?

Vorab muss ich dazu vielleicht noch ergänzen, dass es mir nicht unbedingt nur um die Gegenwart sondern auch um die Vergangenheit geht.

ah, du siehst dich als IT-Historiker? ;-)

Was mich in diesem Zusammenhang stutzig macht, ist die Tatsache, dass es unter dem Tag ssi im Zeitraum 2000 – 2015 keine Einträge gibt?!

Das könnte daran liegen, dass es die derzeitige Forumsversion mit Tags anstatt starren Kategorien erst seit Mitte 2015 gibt. Einen dedizierten Themenbereich SSI gab es AFAIK vorher einfach nicht.

So long,
 Martin

[Julius]

Hallo Martin,

wie sinnvoll ist die Frage überhaupt - angesichts der Tatsache, dass hier im Forum in letzter Zeit schon mehrmals von der Verwendung von SSI abgeraten wurde, weil es von manchen Hostern inzwischen nicht mehr angeboten wird?

Vorab muss ich dazu vielleicht noch ergänzen, dass es mir nicht unbedingt nur um die Gegenwart sondern auch um die Vergangenheit geht.

ah, du siehst dich als IT-Historiker? ;-)

Ich finde es in fast allen Bereichen interessant, warum die Dinge so sind, wie sie sind. Oft liegen sie halt in der Vergangenheit, dafür kann ich nichts :-)

Was mich in diesem Zusammenhang stutzig macht, ist die Tatsache, dass es unter dem Tag ssi im Zeitraum 2000 – 2015 keine Einträge gibt?!

Das könnte daran liegen, dass es die derzeitige Forumsversion mit Tags anstatt starren Kategorien erst seit Mitte 2015 gibt. Einen dedizierten Themenbereich SSI gab es AFAIK vorher einfach nicht.

Es gibt aber von 1999 – 2000 Einträge mit diesem Tag. Zumindest das Wiederauftauchen des Tags ssi etwa vier Monate nach der Einführung von CForum 4 passt etwa. Um 2000 herum wurde ja auch mal die Software gewechselt, aber da kenne ich den Termin nicht.

Gruß
Julius

[Christian Kruse]

Hallo Martin,

Das könnte daran liegen, dass es die derzeitige Forumsversion mit Tags anstatt starren Kategorien erst seit Mitte 2015 gibt.

24.3.2015, um genau zu sein ;-)

Einen dedizierten Themenbereich SSI gab es AFAIK vorher einfach nicht.

Ganz früher, das muss so 99 oder so gewesen sein, gab es diesen Themenbereich.

LG,
CK

[MudGuard]

Hi,

1. PHP und SSI sind beide so 1995-1999 entstanden und der Masse der „Webmaster“ bekannt geworden – es war nicht klar, wer bei Software-Unterstützung, Feature-Reichtum und Akzeptanz gewinnen würde.

Damals™ war es bei den Massenhostern so, daß in den billigeren Paketen SSI dabei war, aber kein PHP oder Perl oder ...

Daher war damals™ SSI stärker im Einsatz als es jetzt ist - trotz der geringen Möglichkeiten - es war teilweise die einzige Möglichkeit, wenigstens ein bißchen serverseitige Technik zu nutzen.

Inzwischen ist PHP fast überall als Grundausstattung vorhanden, und SSI dadurch weitestgehend verdrängt, weil's halt viel mehr Möglichkeiten bietet als SSI.

cu,
Andreas a/k/a MudGuard