Wiedmann wrote:Der Krampf mit fsockopen war aber auch nur eine Notlösung bei PHP4 (falls kein Curl verfügbar war).
Seit PHP5 (anno domini 2003) nimmt man dafür, wie offiziell (und kein ucn) im Handbuch beschrieben, den passenden Stream-Context. Das wirst doch damit jetzt hinbekommen haben?
Ne, ganz ganz sicher nicht. Wenn überhaupt irgendetwas "Krampf" ist, dann ist das der total verkorkste Ansatz des Stream Contexts. Das ist ein schönes Beispiel, wie sich eine Anfangs noch halbwegs vertretbare Idee (normale Dateifunktion via Wrapper auf andere Protokolle zu wrappen) in eine Richtung verselbständigt, die an Sinnlosigkeit und Krampfhaftigkeit nicht zu toppen ist. Auch PHP Entwickler sind offensichtlich nur Menschen.
Was haben wir denn?
Irgendwann kam mal jemand auf die Idee, die normalen Dateifunktionen auch auf andere Protokolle zu wrappen. Diese Schnittstelle, die ich da schon zweifelhaft fand, hatte ihre einzige Existenzberechtigung darin, den unbedarften Programmierer nicht mit Kenntnissen etwas schwierigerer Protokolle (wie beispielsweise HTTP) zu belasten. Ein simple fopen() oder file_get_content() usw. führt im Zweifel einen GET-Request auf eine URL aus. Fand ich wie gesagt immer schon zweifelhaft, aber immerhin konnte man damit auch ohne Kenntnisse von HTTP einfache Requests durchführen. Für die anspruchsvolleren Dinge gab (und gibt es zum Glück) natürlich die Möglichkeit, etwas näher am Protokoll mit fsockopen vollständige Requests auszuführen.
Dann fiel offensichtlich jemand auf, dass natürlich die Möglichkeiten des Wrappers sehr beschränkt sind - das liegt in der Natur der Sache, wenn man eine stark vereinfachte API anbieten will. Und anstatt das nun so zu lassen wie ist, wurde die völlig kaputte Idee entwickelt, für die anspruchsvolleren Dinge einen Stream Context zu definieren. Nur - für wen ist denn diese Schnittstelle gedacht? Die Bedienung ist keinesfalls einfacher als über die bekannte API fsockopen() usw., sie erfordert gleichermaßen massive Kenntnisse über das benötigte Protokoll (im Prinzip muss der komplette Request definiert werden, je nach Anspruch) um dann schließendlich (Halleluja!) nach intensiven und tiefgreifenden Kenntnis erfordernden Vorbereitung "endlich" doch die (dafür eigentlich nie angedachte) file-Funktion verwenden zu können, wrappen um des wrappens Willen, sinnfrei und schlecht bedienbar. Der Programmcode ist weder einfacher, noch kürzer, noch besser wartbar, noch besser bedienbar.
Krampf hoch zehn! Und was gewinnt man: nichts! Weil der Programmierer, der die Protokolle kennt, schon seit anno dunnemal fsockopen benutzt, und weil die Programmierer, die die Protokolle nicht kennen, auch die Stream Sockets nicht bedienen können. Und weil das alles problemlos, mit nahezu identischen Programmzeilen seit eh und je via fsockopen möglich war und ist - und da gehört es auch hin. Nur um mit Allgewalt einen Teil der file-Funktionen bedienen zu können, wird so ein Riesenkrampf veranstaltet? Die darf benutzen wer will - ich benutze sie ganz sicher nicht.