POST an OData Service mit PHP Klasse
0 
dedlfix
0 0 0 0 0 0 1
0
POST an OData Service mit PHP Klasse
Hallo Forum,
ich verwende die OData Klasse von M$ (http://odataphp.codeplex.com/) um mit PHP OData-Services abzufragen. Lesende Abfragen haben bisher gut funktioniert. Nun habe ich versucht Daten an den Service zu senden. In der Theorie sollte das auch recht leicht abgehen. Mein Code:
require_once("/lib/MYSERVICE.php"); // Proxy Klasse
$proxy = new MYSERVICE();
$replacement = replacement::Createreplacement( $data->val1,
$data->val2,
$data->val3,
'',
'',
''
);
$proxy->AddToreplacements($replacement);
$proxy->SaveChanges();
Leider kommt bei Ausführung von $proxy->SaveChanges(); immer ein Fehler:
<b>Strict Standards</b>: Non-static method Utility::WriteLine() should not be called statically, assuming $this from incompatible context in <b>C:\Program Files (x86)\Zend\ZendServer\data\apps\http\swro-ws-develop.local\80\lib\odataphp\Context\SaveResult.php</b> on line <b>186</b><br />
<br />
<b>Strict Standards</b>: Non-static method Utility::WriteLine() should not be called statically, assuming $this from incompatible context in <b>C:\Program Files (x86)\Zend\ZendServer\data\apps\http\swro-ws-develop.local\80\lib\odataphp\Context\SaveResult.php</b> on line <b>188</b><br />
[...]
Diese Utility::WriteLine() wird über X-Zeilen angemeckert. Tatsächlich wird in SaveResult.php in vielen Zeilen die WriteLine() Methode aufgerufen. Keine Ahnung warum die Klasse an der Stelle rumzickt. Sie gilt eigentlich schon länger als stable. Die Dokumentation ist ja leider mehr als dürftig. Außer ein paar Blog-Posts oder Forumseinträge findet man hier nicht viel.
Hat jemand von Euch schonmal Erfahrungen mit dieser OData-Klasse gemacht und kennt vielleicht diesen Fehler? Bzw. weiß einer vielleicht, ob es in der PHP Welt irgendwo ne gute Alternative im Bereich OData gibt? Bin für jeden Tipp offen.
Wir benötigen im Unternehmen OData für die Anbindung von mobilen Apps. Nachdem OData ja seit einiger Zeit von einigen marktführenden Unternehmen zum Industriestandard erhoben wurde, war ich doch einigermaßen erstaunt, dass das Angebot passender APIs in PHP für eine OData Implementierung doch recht spärlich ausfällt.
Vielen Dank für Eure Infos
Stephan
-
Tach!
Leider kommt bei Ausführung von $proxy->SaveChanges(); immer ein Fehler:
<b>Strict Standards</b>: Non-static method Utility::WriteLine() should not be called statically, assuming $this from incompatible context in <b>C:\Program Files (x86)\Zend\ZendServer\data\apps\http\swro-ws-develop.local\80\lib\odataphp\Context\SaveResult.php</b> on line <b>186</b><br />Das ist kein Fehler an sich, das ist nur ein Hinweis, dass das keine saubere Programmierung ist. Kannst du im allgemeinen ignorieren, wenn es ansonsten läuft. Stell das error_reporting nicht ganz so strikt ein, also E_ALL ohne E_STRICT.
dedlfix.
-
hi,
Wir benötigen im Unternehmen OData für die Anbindung von mobilen Apps. Nachdem OData ja seit einiger Zeit von einigen marktführenden Unternehmen zum Industriestandard erhoben wurde, war ich doch einigermaßen erstaunt, dass das Angebot passender APIs in PHP für eine OData Implementierung doch recht spärlich ausfällt.
Mich erstaunt das nicht, OData sieht eher nach einer laienhaften Bastelei aus.
<wiki>
Die Organization for the Advancement of Structured Information Standards (OASIS) ist eine internationale, nicht-gewinnorientierte Organisation, die sich mit der Weiterentwicklung von E-Business- und Webservice-Standards beschäftigt.
</wiki>Das erstaunt mich schon eher, insbesondere der Begriff nicht-gewinnorientiert im Zusammenhang mit E-Business ;)
&SNCR;
-
Hakuna matata!
Mich erstaunt das nicht, OData sieht eher nach einer laienhaften Bastelei aus.
Was konkret findest du denn unprofessionell an OData? Ich kann deine Einschätzung nicht teilen, habe mich aber auch noch nie intensiv mit OData beschäftigt.
<wiki>
Die Organization for the Advancement of Structured Information Standards (OASIS) ist eine internationale, nicht-gewinnorientierte Organisation, die sich mit der Weiterentwicklung von E-Business- und Webservice-Standards beschäftigt.
</wiki>Das erstaunt mich schon eher, insbesondere der Begriff nicht-gewinnorientiert im Zusammenhang mit E-Business ;)
Standardisierungs-Orgoanisationen sind doch meistens nicht gewinnorientiert. Die Mitglieder vertreten häufig natürlich trotzdem die Interessen irgendwelcher Wirtschaftsriesen. Das ist beim W3C, dem WhatWG, Ecma International und der Khronos Group nicht anders.
--
“All right, then, I'll go to hell.” – Huck Finn-
Hakuna matata!
Mich erstaunt das nicht, OData sieht eher nach einer laienhaften Bastelei aus.
Was konkret findest du denn unprofessionell an OData? Ich kann deine Einschätzung nicht teilen, habe mich aber auch noch nie intensiv mit OData beschäftigt.
Menschen lesen Sequenzen anders als Maschinen.
Menschenlesbar
MaschinenlesbarFür den 2. Link habe ich lediglich den Content-Type: text/plain gesetzt, damit der Browser die Binary zeigen kann. Der 1. Link zeigt dieselbe Binary als Dump.
Ein BOT schnappt sich die Binary in Bruchteilen von Sekunden und kann unmittelbar mit dem Empfang der ersten Bytes mit der Verarbeitung beginnen (z.B. HEAD-Requests auf jeden URL feuern).
Einen Dump (ähnlich JSON) muss eine Maschine komplett in den Hautpspeicher laden, damit er geparst werden kann (gilt auch für XML).
Für viele Anwendungsfälle reichen zyklische Sequenzen, guck Dir den Dump an, die Struktur entspricht dem Muster Entity-Attribute-Value. Ein Serializer für dieses Muster ist sehr einfach zu implementieren (und auch portable), das schafft eine transparente Übertragung zwischen verschiedenen Plattformen, beispielsweise hätten wir damit serverseitig wie clientseitig dieselbe Datenstruktur und die ist vom Übertragungsweg (HTTP, Pipes, Sockets, IO) vollständig abstrahiert.
Es müssen also nicht unbedingt Sequenzen sein mit beliebiger Schachtelung, die rekursiv durchlaufen werden müssen. Obwohl es auch dafür Serializer gibt, die sehr performant arbeiten wie z.B. Perl::Storable.pm
Ich denke, dass eine Standardisierung in diese Richtung gehen sollte, nicht zeichenorientiert sondern byteorientiert und vom Übertragungsweg vollständig entkoppelt. Schließlich wollen wir auch Bilder, Video, Audio und nicht nur Texte.
Schöne Grüße.
PS: Das Content-Management für mein WebSite läuft seit Jahren über einen Webservice, ebenso das Remote-DB-Management u.a. Remote-Procedure-Calls. Fernab von XML, einfach und zuverlässig. Beim Publizieren einer Seite mit eingebauten Bildern, werden letztere gleich mit übertragen. Mit XML oder JSON ist sowas nicht zu machen.
--
In Orientierung steckt das Wort Orient.-
Auch ich nix OData kennen...
Menschen lesen Sequenzen anders als Maschinen.
Menschenlesbar
MaschinenlesbarFür den 2. Link habe ich lediglich den Content-Type: text/plain gesetzt, damit der Browser die Binary zeigen kann. Der 1. Link zeigt dieselbe Binary als Dump.
Du vergisst zu erwähnen, dass "Dein Binary" im zweiten Link nicht nur einen anderen Content-Type hat, sondern auch durch etwas magisches auf Deiner Seite gelaufen ist und danach durch Data::Dumper gejagt wurde.
Ein BOT schnappt sich die Binary in Bruchteilen von Sekunden und kann unmittelbar mit dem Empfang der ersten Bytes mit der Verarbeitung beginnen (z.B. HEAD-Requests auf jeden URL feuern).
Bei wirklich großen Datenmengen kann eine sequentielle Verarbeitung sinnvoll sein, ja. Das bedeutet noch lange nicht, dass das innerhalb des Austauschsformats passieren muss.
Einen Dump (ähnlich JSON) muss eine Maschine komplett in den Hautpspeicher laden, damit er geparst werden kann (gilt auch für XML).
Skizzier mal bitte Dein Szenario an einem konkreten Beispiel(ohne Bilder/Audio, siehe unten), Dein Dump umfasst aktuell ~ 6 Kilobyte. Bei 600 Kilobyte könnte man ansatzweise über einen Vorteil nachdenken.
Ich denke, dass eine Standardisierung in diese Richtung gehen sollte, nicht zeichenorientiert sondern byteorientiert und vom Übertragungsweg vollständig entkoppelt. Schließlich wollen wir auch Bilder, Video, Audio und nicht nur Texte.
Ich denke, dass man genau das nicht will. Wenn ich Deine Schnittstelle anzapfe und diese enthält in Ihrer Antwort Audio/Video, dann ist das doof. Bei jedem Aufruf wird massiver Overhead übertragen, denn ich gar nicht möchte / brauche. Wenn Du mir stattdessen einen Link und eine Prüfsümme für tatsächliche Binärdaten übertragen würdest, könnte ich auf meiner Seite überprüfen, ob ich diese überhaupt neu laden muss.
[...] Beim Publizieren einer Seite mit eingebauten Bildern, werden letztere gleich mit übertragen. Mit XML oder JSON ist sowas nicht zu machen.
Klar geht das: Base64. Man kann frei entscheiden, ob man den Overhead möchte oder lieber eine Lösung wie oben skizziert verfolgt.
-
Auch ich nix OData kennen...
Menschen lesen Sequenzen anders als Maschinen.
Menschenlesbar
MaschinenlesbarFür den 2. Link habe ich lediglich den Content-Type: text/plain gesetzt, damit der Browser die Binary zeigen kann. Der 1. Link zeigt dieselbe Binary als Dump.
Du vergisst zu erwähnen, dass "Dein Binary" im zweiten Link nicht nur einen anderen Content-Type hat, sondern auch durch etwas magisches auf Deiner Seite gelaufen ist und danach durch Data::Dumper gejagt wurde.
Nein, kein Data::Dumper. Der 2. Link serialisiert einfach nur die serverseitig im Hauptspeicher liegende Routing-Table. Der Content-Type ist für den BOT absolut uninteressant. Ich könnte genausogut application/octet-stream senden oder foo/bar.
Ein BOT schnappt sich die Binary in Bruchteilen von Sekunden und kann unmittelbar mit dem Empfang der ersten Bytes mit der Verarbeitung beginnen (z.B. HEAD-Requests auf jeden URL feuern).
Bei wirklich großen Datenmengen kann eine sequentielle Verarbeitung sinnvoll sein, ja. Das bedeutet noch lange nicht, dass das innerhalb des Austauschsformats passieren muss.
Beachte den Dateibegriff nach Niklaus Wirth: Dateien sind Sequenzen. Abstrakt: Alles was den Hauptspeicher verlassen soll, egal ob in eine Datei, ein PIPE, STDOUT, ein Socket (HTTP)... ist eine Byte-Sequenz. Sequenzen werden sequentiell erzeugt und sequentiell gelesen. Sequenzen enthalten Datenstrukturen, ein bestimmter Serialize-Algorithmus vermittelt zwischen einer Sequenz und der im Hauptspeicher vorliegenden Datenstruktur (Array, Hash, Refereenzen, Zeiger).
Das bedeutet, dass ein wahlfreier Zugriff (Random Access) nicht etwa in einer Sequenz abgebildet ist, sondern einzig über den Hauptspeicher erfolgt.
N. Wirth um 1980. Letztendlich sind XML und JSON auch nur gewöhnliche Sequenzen.
Einen Dump (ähnlich JSON) muss eine Maschine komplett in den Hautpspeicher laden, damit er geparst werden kann (gilt auch für XML).
Skizzier mal bitte Dein Szenario an einem konkreten Beispiel(ohne Bilder/Audio, siehe unten), Dein Dump umfasst aktuell ~ 6 Kilobyte. Bei 600 Kilobyte könnte man ansatzweise über einen Vorteil nachdenken.
Der Dump dient nur einer bildlichen Veranschaulichung. Er weist jedoch dem Programmierer den Weg für den wahlfreien Zugriff in den Hauptspeicher: $body = $bin->{'/index.html'}{body}.
Eingepackt hat meine $bin eine Größe von 1.3MB als XML verpackt wäre sie wesentlich größer. Der Dump zeigt jedoch nicht alle Attribute.
Bei jedem Aufruf wird massiver Overhead übertragen, denn ich gar nicht möchte / brauche. Wenn Du mir stattdessen einen Link und eine Prüfsümme für tatsächliche Binärdaten übertragen würdest, könnte ich auf meiner Seite überprüfen, ob ich diese überhaupt neu laden muss.
Webservice: Der Request wird spezialisiert unter Einbeziehung der Request-Method und ggf. der im Request enthaltenen Parameter.
Ein proprietärer Standard könnte z.B. festlegen, dass grundsätzlich nur ein PUT-Request erfolgt und einzig die aus der gesendeten Sequenz erzeugte Datenstruktur darüber entscheidet, welche Aktionen serverseitig auszuführen sind. Auf diese Art und Weise funktioniert mein Content-Management, ich sende eine Datei an meinen Webservice, darin liegt z.B. alles, was eine Response auf /index.html braucht. Mein Webservice baut dann die index.html samt Body u.a. Attribute in die Binary ein. Das ganze wird über den Hauptspeicher abgewickelt und im DESTROY wird die $bin aus dem Hauptspeicher zurück auf die Festplatte geschrieben.
Demo:
D:>lwp-request -m PUT http://rolfrost.de/binf.html
Please enter content (text/plain) to be PUTed:
asdf123 foo bar
^Z
PUTDATA:
asdf123 foo bar[...] Beim Publizieren einer Seite mit eingebauten Bildern, werden letztere gleich mit übertragen. Mit XML oder JSON ist sowas nicht zu machen.
Klar geht das: Base64. Man kann frei entscheiden, ob man den Overhead möchte oder lieber eine Lösung wie oben skizziert verfolgt.
Achja, die gute alte ASCII-Welt. Der ganze MIME-Standard ist sowas von Schrott und da bin ich nicht der Einzige der so denkt ;)
-
-
Hakuna matata!
Einen Dump (ähnlich JSON) muss eine Maschine komplett in den Hautpspeicher laden, damit er geparst werden kann (gilt auch für XML).
Nein, das ist falsch.
Siehe dir zum Beispiel mal die Bibliothek json-parse-steam auf Github an. Oder im Falle von HTML/XML: htmlparser2.Für viele Anwendungsfälle reichen zyklische Sequenzen, guck Dir den Dump an, die Struktur entspricht dem Muster Entity-Attribute-Value. Ein Serializer für dieses Muster ist sehr einfach zu implementieren (und auch portable)
Und JSON- und XML-Parser gibt es bereits fertig implementiert für jede Programmierumgebung. Wieso sollte man das Rad neuerfinden? Versetz dich doch mal in die Lage der OData-Entwickler:
Typ A: „Ey, welche Datenformate wollen wir unterstützen?“
Typ B: „Jeder Webentwickler ist mit JSON und XML vertraut, es gibt Bibliotheken wie Sand am Meer, beide Formate sind beliebt, erprobt und state-of-the-art.“
Typ C: „Ach Schman, pass auf: Wir erfinden das Rad neu und entwickeln unser ganz eigenes Format, das viel besser ist als JSON und XML zusammen. Das wird die OData-Nutzer sicher begeistern.“
Typ A: „Großartiger Vorschlag, Typ C. Typ B? Sie sind gefeuert. Wir wollen nicht dastehen wie Laien“Ich denke, dass eine Standardisierung in diese Richtung gehen sollte, nicht zeichenorientiert sondern byteorientiert und vom Übertragungsweg vollständig entkoppelt. Schließlich wollen wir auch Bilder, Video, Audio und nicht nur Texte.
Schieß dir nichts ins eigene Knie. Wenn du zwei Videos eingebettet in einer Sever-Antwort überträgst, dann muss das erste Video vollständig runtergeladen sein, bevor man überhaupt den ersten Frame des zweiten Videos weiterverarbeiten kann.
Da ist es wesentlich klüger, statt der eingebetteten Videos, nur die URLs der Videos zu übertragen und dem Client die Chance zu geben, die Videos parallel herunterzuladen. Sowie OData es handhabt.
--
“All right, then, I'll go to hell.” – Huck Finn-
Hakuna matata!
Einen Dump (ähnlich JSON) muss eine Maschine komplett in den Hautpspeicher laden, damit er geparst werden kann (gilt auch für XML).
Nein, das ist falsch.
Siehe dir zum Beispiel mal die Bibliothek json-parse-steam auf Github an. Oder im Falle von HTML/XML: htmlparser2.Vergleich das mal Hiermit. Ein Serializer arbeitet nicht mit Tokens, sondern mit Längenangaben (8, 16, 32, 64 Bit). JS kennt zwar den ArrayBuffer und DataView, aber ich habe nichts dergleichen in o.g. Sourcen gefunden.
Und JSON- und XML-Parser gibt es bereits fertig implementiert für jede Programmierumgebung. Wieso sollte man das Rad neuerfinden?
Unsinn. Wer mit Bytes operiert, erfindet doch das Rad nicht neu.
Schönen Abend ;)
-
Hakuna matata!
Einen Dump (ähnlich JSON) muss eine Maschine komplett in den Hautpspeicher laden, damit er geparst werden kann (gilt auch für XML).
Nein, das ist falsch.
Siehe dir zum Beispiel mal die Bibliothek json-parse-steam auf Github an. Oder im Falle von HTML/XML: htmlparser2.Vergleich das mal Hiermit. Ein Serializer arbeitet nicht mit Tokens, sondern mit Längenangaben (8, 16, 32, 64 Bit).
Sowohl der JSON-Parser als auch der XML-Parser, die ich dir gezeigt habe, können Datenstreams on-the-fly parsen. Jetzt schmeckt dir die Implementation nicht?
JS kennt zwar den ArrayBuffer und DataView, aber ich habe nichts dergleichen in o.g. Sourcen gefunden.
Wieso auch? Nur zum Selbstzeck?
Und JSON- und XML-Parser gibt es bereits fertig implementiert für jede Programmierumgebung. Wieso sollte man das Rad neuerfinden?
Unsinn. Wer mit Bytes operiert, erfindet doch das Rad nicht neu.
Okay, dir fehlen scheinbar einige Grundlagen.
Bytes ohne Angabe über die Kodierung sind wertlos. Kein Mensch oder Computer der Welt kann was mit Binärsequenzen anfangen, wenn man ihm nicht sagt, wie er die Daten zu interpretieren hat. Dafür braucht man mindestens noch eine Zusatzinformation: Die Kodierung. Ein paar Beispiele, um dir das klar zu machen:
Fließkommazahlen können als Double-Precision-Floating-Point gespeichert werden.
Strings können in UTF8, UTF16 oder ASCII kodiert sein.
Videos können OGG kodiert sein.
Audiodateien können MP3 kodiert sein.
DOM-Dokumente können XML oder HTML kodiert sein.
Datenstrukturen (zumindest einige) kann man als JSON kodieren.Alle diese Dinge werden auf der Festplatte oder im Hauptspeicher irgendwie als Sequenzen von Bytes gespeichert. Wenn man nicht dazu sagt, WIE diese Bytesequenzen zu verstehen sind, dann kann man mit den Daten auch nichts anfangen. Das WIE ist also wichtig, das sagt uns, dass es sich um eine Video handelt und wie man dieses abspielen kann.
Den Vorgang eine Bytesequenz in eine verwertbare Datenstruktur zu überführen nennt man Dekodieren. Im Falle von Austauschdatenformaten oder Programmiersprachen spricht man auch oft von Parsern. Den umgekehrten Vorgang Datenstrukturen in Bytesequenzen zu überführen, nennt man kodieren oder serialisieren
Das Ergebnis einer Kodierung muss nicht gleich eine Binärsequenz sein. Ebensowenig müssen die Eingabedaten für eine Dekodierung immer Binärsequenzen sein. Es ist üblich, dass man verschiedene Kodierungen schichtet, zum Beispiel: DOM-Dokumente können HTML kodiert werden, die HTML-Zeichenkette kann dann UTF8 kodiert werden, um eine Binärpräsentation der Daten zu erhalten.
Wenn ein Webservice ein Datenaustauschformat unterstützen will, sei es XML, JSON oder dein selbstgestricktes hotti-eav-binär-Format, dann muss auf der serverseite also ein Kodierer/Serialisierer existieren. Auf der clientseite muss ein Dekodierer/Deserialisierer/Parser existieren.
Für JSON und XML sind sowohl Kodierer als auch Dekodierer weit verbreitet. Für dein benutzerdefiniertes Format gibt es, außer deiner eigenen Implementation, keine weitere Bibliotheken.
Um dein Statement nochmal aufzugreifen:
Unsinn. Wer mit Bytes operiert, erfindet doch das Rad nicht neu.
Wenn man für jede Umgebung erst einen eigenen Kodierer und Dekodierer implementieren muss, dann kann man sagen, dass man das Rad neuerfindet.
--
“All right, then, I'll go to hell.” – Huck Finn-
Hakuna matata!
Sowohl der JSON-Parser als auch der XML-Parser, die ich dir gezeigt habe, können Datenstreams on-the-fly parsen. Jetzt schmeckt dir die Implementation nicht?
Siehe meine erste Anmwerkung zu diesem Thema: Die OData-Entwickler erfinden das Rad neu. Mit wenigen Zeilen Perl kannst Du ganze Datenbanken via HTTP übertragen. Diesbez. Serializer und Low-Level-HTTP-Client gibt es seit Jahren.
Bytes ohne Angabe über die Kodierung sind wertlos.
Bytes kennen überhaupt keine Kodierung. Andererseits kannst Du selbstverständlich auch diese Informationen übertragen. Und was mit Perl geht, das geht auch mit anderen PLs.
Wenn ein Webservice ein Datenaustauschformat unterstützen will, sei es XML, JSON oder dein selbstgestricktes hotti-eav-binär-Format, dann muss auf der serverseite also ein Kodierer/Serialisierer existieren. Auf der clientseite muss ein Dekodierer/Deserialisierer/Parser existieren.
Es gibt Perl-Versionen, da ist der im Core mitgelieferte Serializer nicht kompatibel. Für mich kein Grund, auf XML umzusteigen, ein eigener Serializer für zyklische Strukturen ist denkbar einfach gestrickt.
Für JSON und XML sind sowohl Kodierer als auch Dekodierer weit verbreitet. Für dein benutzerdefiniertes Format gibt es, außer deiner eigenen Implementation, keine weitere Bibliotheken.
Es gibt sogar in Sachen Serializer einige Neuentwicklungen auf CPAN.
Und nochwas zum Thema MIME: Meine Maildatei der Zukunft wäre eine Hyper-Media-Datei (Multipart), die den 8-Bit-Bereich nutzt und sowas wie Trennlinien (Boundary), Base64 oder Quoted-Printable gar nicht braucht. Ich wäre kein Entwickler, wenn ich bisherige Standards und auch eigene Entwicklungen nicht kritisch betrachten würde. Darüber hinaus war es in der Geschichte schon immer so, dass 'Standards' nicht unbedingt den neuesten Stand der Entwicklung repräsentieren. Siehe VE 301: Etwa zur selben Zeit von Loewe entwickelte Radios, bestückt mit Mehrfachröhren (v. Ardenne) hätten die Bezeichnung Volksempfänger weit mehr verdient.
Schöne Grüße.
-
use strict; use warnings; use IO::File; use Data::Dumper; use 5.010; use Storable qw(freeze thaw); # Prepare Attachment my $gif_binary = do{ my $fh = IO::File->new; $fh->open('red.gif', O_RDONLY|O_BINARY) or die $!; read($fh, my $buffer, -s $fh); $fh->close; $buffer; }; # Einheitliche Datenstruktur my $mail = [ { role => 'header', mta => 'localhost', mesgid => 123456789, date => scalar localtime, }, { role => 'header', from => 'hugo@example.org', to => 'lupo@example.com', subject => 'Multi-Media-Mail' }, { role => 'part', type => 'text/plain; Charset=UTF-8', body => 'Inhalt der Nachricht als Text' }, { role => 'part', type => 'image/gif', body => $gif_binary, label => 'Ein bischen Grafik', filename => 'red.gif' } ]; # Serialize my $file = freeze($mail); # Übertragung: Jeder MTA fügt am Anfang der Datei einen Block mit role => 'header' hinzu # Dieser Block hat eine variable Länge und kann beliebige Informationen enthalten # Z.B. den Return-Path # Deserialize # Das macht der Mailclient nach der Übertragung say Dumper thaw($file);Am Anfang steht immer die Idee: Weniger Overhead, kleine Bandbreiten und ein gemeinsamer Standard für SMS, MMS, Mail. Diesbezügliche Gremien gibt es (z.B. 3GPP, OMA usw.), die müssten nur mal richtig miteinander reden ;)
-
Hakuna matata!
Sowohl der JSON-Parser als auch der XML-Parser, die ich dir gezeigt habe, können Datenstreams on-the-fly parsen. Jetzt schmeckt dir die Implementation nicht?
Siehe meine erste Anmwerkung zu diesem Thema: Die OData-Entwickler erfinden das Rad neu. Mit wenigen Zeilen Perl kannst Du ganze Datenbanken via HTTP übertragen. Diesbez. Serializer und Low-Level-HTTP-Client gibt es seit Jahren.
Wir versuchen doch zu klären, was an OData unprofessionell ist. Einer deiner Kritikpunkte war, dass die verwendeten Austauschformate (JSON und XML) nicht geparst werden können, bevor alle Daten vorliegen. Ich habe dir anhand von zwei Bibliotheken bewiesen, dass du damit falsch liegst. Dieser Kritikpunkt dürfte sich also erledigt haben.
Ein anderer Kritikpunkt war, dass man in XML und JSON keine Mediendateien einbetten kann. Auch das ist faktisch falsch. Davon abgesehen ist es sowieso keine gute Idee große Mediendateien in Austauschformate einzubetten. Das haben wir alles schon ausdiskutiert.
Jetzt bringst du einen neuen Kritikpunkt ins Spiel, und erklärst dass man mit Perl mit wenigen Zeilen Code ganze Datenbanken übertragen kann. Und dazu kann ich nur sagen, das ist toll, aber das ist eben keine Anforderung, die man mit einem REST-Service zu erfüllen versucht. REST-Services sollen eine einfache und konsistente API zur Verfügung stellen, um die CRUD-Operationen auf einem entfernten Datenbanksystem auszuführen. Replikation ist ein anderes Thema. Ein Service-Provider könnte Replikation intern implementieren, um zum Beispiel Load-Balancing oder Ausfallsicherheit zu garantieren. Das ist aber wie gesagt eine internes Implementations-Detail und muss nicht über die REST-API nach außen getragen werden. Im übrigen ist das reine Kopieren der Datenbank keine besonders klevere Lösung für Replikation. Ich kann also auch in diesem Punkt nicht erkennen, was an OData "laienhaft zusammengeschustert" sein soll.
Bytes ohne Angabe über die Kodierung sind wertlos.
Bytes kennen überhaupt keine Kodierung.
Lies den Satz bitte nochmal. Ich habe nie gesagt Bytes kennen eine Kodierung. Ich sagte Bytesequenzen ohne eine Angabe über ihre Kodierung sind wertlos. Die Daten erhalten erst eine Semantik, wenn man dazu eine Kodierung angibt.
Wenn ein Webservice ein Datenaustauschformat unterstützen will, sei es XML, JSON oder dein selbstgestricktes hotti-eav-binär-Format, dann muss auf der serverseite also ein Kodierer/Serialisierer existieren. Auf der clientseite muss ein Dekodierer/Deserialisierer/Parser existieren.
Es gibt Perl-Versionen, da ist der im Core mitgelieferte Serializer nicht kompatibel.
Wozu soll welcher Serializer nicht kompatibel sein?
Für mich kein Grund, auf XML umzusteigen, ein eigener Serializer für zyklische Strukturen ist denkbar einfach gestrickt.
Das mag alles sein, aber soll sich denn wirklich jeder Entwickler, der einen REST-Service konsumieren will, selber einen Deserializer/Parser bauen? Kann man als REST-Service-Provider wirklich von seinen Benutzern verlangen, dass sie ein neues, total unbekanntes Datenformat lernen? Das wäre wirklich unprofessionell. Es ist doch tausend mal klüger auf erprobte und weit verbreitete Formate zu setzen.
Für JSON und XML sind sowohl Kodierer als auch Dekodierer weit verbreitet. Für dein benutzerdefiniertes Format gibt es, außer deiner eigenen Implementation, keine weitere Bibliotheken.
Es gibt sogar in Sachen Serializer einige Neuentwicklungen auf CPAN.
Da du CPAN schon selber anführst, such doch mal nach JSON oder XML. Das spricht doch wieder nur für diese beiden Formate.
Ich wäre kein Entwickler, wenn ich bisherige Standards und auch eigene Entwicklungen nicht kritisch betrachten würde.
Ich lese mir gerne Kritik durch, deswegen habe ich ja auch nochmal gezielt nachgefragt, worin deine negative Bewertung begründet ist. In diesem Fall hast du dich aber mit deiner Kritik geirrt, denn wir konnten ja objektiv nachvollziehen, dass sie auf falschen Annahmen und Unwissen beruht. Das ist alles kein Beinbruch, es ja tut niemanden weh.
Darüber hinaus war es in der Geschichte schon immer so, dass 'Standards' nicht unbedingt den neuesten Stand der Entwicklung repräsentieren.
Das ist kein Argument sich generell gegen Standards oder insbesondere gegen OData zu wenden.
--
“All right, then, I'll go to hell.” – Huck Finn-
hi,
Da du CPAN schon selber anführst, such doch mal nach JSON oder XML. Das spricht doch wieder nur für diese beiden Formate.
Es spricht für Perl und für CPAN. Ich bin oft auf CPAN unterwegs, nicht auf der Suche nach Modulen, sondern vorzugsweise auf der Suche nach Ideen.
Darüber hinaus war es in der Geschichte schon immer so, dass 'Standards' nicht unbedingt den neuesten Stand der Entwicklung repräsentieren.
Das ist kein Argument sich generell gegen Standards oder insbesondere gegen OData zu wenden.
Das ist ein sehr entscheidendes Argument. Wenn ich der Meinung bin, dass ich bestimmte Dinge effizienter und auch einfacher lösen kann, dann setze ich mich nicht nur sehr intensiv mit dem Thema auseinander sondern setze meine Ideen auch in die Praxis um. Darüber hinaus erstelle ich funktionierende Demo-Anwendungen und dokumentiere das in einer sehr verständlichen Form. Das Verständnis allerdings muss jeder selbst entwickeln.
Odata? Ja, damit arbeite ich schon lange. Wer XML oder JSON von mir haben will, der kriegt das auch. REST, SOAP? Wenn ich nicht wüsste, was das ist und noch weniger, wenn ich keine Praxis damit hätte: Ich würde mir jegliche Kritik verkneifen. Ich kenne Firmen, die ersticken im CODE, aber warum einfach, wenns komplizierter geht ;)
Es wird Zeit, den MIME-Standard abzulösen:
SMS, MMS, Internet-Mail, WebsocketSchöne Grüße!
-
Es wird Zeit, den MIME-Standard abzulösen:
SMS, MMS, Internet-Mail, Websocket<Zitat>
Deserialize
Das macht der Mailclient nach der Übertragung
say Dumper thaw($pipe);
</Zitat>Aaah, jetzt wird mir einiges klar! Endlich Schluss mit der scheiß Abwärtskompatibilität und einfach mal was Neues raushauen! Sollen die Leute sich doch einfach meinen (und in Zukunft von zig anderen nach selbem Gusto implementierten) E-Mail-Client runterladen, wenn Sie meine modernen E-Mails lesen wollen! Die doofen Webmail-Anbieter ziehen dann eh sofort nach!
Nur für den sehr unwahrscheinlichen Fall, dass die weltweite Umstellung dann doch an irgendwelchen blöden Fortschrittsverweigerern und ängstlichen Firmenadmins haken sollte: Hey, wir packen die moderne Lösung einfach zunächst als zusätzlichen Teil in die althergebrachte Multipart-Message und die E-Mail kann dann von alten wie neuen Clients gelesen werden. Perfekt!
Dass jede E-Mail dann doppelt so groß wird? Scheiß drauf! Weg mit den alten Zöpfen!
-
-
-
-
-
-
-
-
-
-
Moin!
ich verwende die OData Klasse von M$ (http://odataphp.codeplex.com/) um mit PHP OData-Services abzufragen. Lesende Abfragen haben bisher gut funktioniert. Nun habe ich versucht Daten an den Service zu senden. In der Theorie sollte das auch recht leicht abgehen.
Ich hab mir den Code von dieser Seite mal kurz angeschaut.
ES GIBT ZUM GLÜCK WENIG CODE, DEN ICH SO EXTREM UNGERN NUTZEN WÜRDE, WIE DIESEN.
Das Copyright ist von 2010 - und ungefähr genau so lange hat auch niemand mehr an diesem Code gearbeitet (immerhin schon 5 Jahre!) und ihn auf das aktuelle Niveau moderner PHP5-Applikationen gehoben. Es wimmelt noch von Resten von PHP-4-Code in dieser Software!!!
Abgesehen davon kann man sie nicht mit Composer installieren und nutzen. Von meiner Warte aus kriegt dieses Paket ein dickes, fettes Daumen runter.
Leider kommt bei Ausführung von $proxy->SaveChanges(); immer ein Fehler:
Das ist einer der Nachteile, wenn man als Anbieter seine Software nicht pflegt: Irgendwann ist es halt kaputt.
Im Gegensatz zu dedlfix sehe ich diese Warnung als sehr deutliches Signal, von der weiteren Nutzung abzusehen. Es wird über kurz oder lang zu Inkompatibilitäten mit neuen PHP-Releases kommen.
Die Tatsache, dass man außer dieser Lib zu "OData" im PHP-Umfeld fast nichts findet (selbst die offiziell aussehende http://www.odata.org/libraries listet KEINE EINZIGE PHP-Library), deutet auch darauf hin, dass PHP-Entwickler diesen Standard als eher irrelevant einschätzen. Das ist natürlich Pech, wenn man einen entsprechenden Service konsumieren muss, aber angesichts dieser Situation von Software-Aktualität fühlt es sich für mich sowieso so an, als reite man da ein totes Pferd.
Diese Utility::WriteLine() wird über X-Zeilen angemeckert. Tatsächlich wird in SaveResult.php in vielen Zeilen die WriteLine() Methode aufgerufen. Keine Ahnung warum die Klasse an der Stelle rumzickt. Sie gilt eigentlich schon länger als stable. Die Dokumentation ist ja leider mehr als dürftig. Außer ein paar Blog-Posts oder Forumseinträge findet man hier nicht viel.
Debugging in offen vorliegendem Sourcecode ist ja kein Hexenwerk - den Bug könntest du fixen. Nützt nur leider niemandem: Dem Rest der Welt nicht, weil der davon nix hat, und euch nicht, weil ihr damit in die Pflege dieser Library einsteigt. Obwohl: Das seid ihr ohnehin schon, ihr habt das vermutlich nur noch nicht realisiert: Eine fünf Jahre alte PHP-Library erhält vom Hersteller keinen Support mehr, den müsst ihr ganz allein und eigenständig machen...
Hat jemand von Euch schonmal Erfahrungen mit dieser OData-Klasse gemacht und kennt vielleicht diesen Fehler? Bzw. weiß einer vielleicht, ob es in der PHP Welt irgendwo ne gute Alternative im Bereich OData gibt? Bin für jeden Tipp offen.
Wir benötigen im Unternehmen OData für die Anbindung von mobilen Apps. Nachdem OData ja seit einiger Zeit von einigen marktführenden Unternehmen zum Industriestandard erhoben wurde, war ich doch einigermaßen erstaunt, dass das Angebot passender APIs in PHP für eine OData Implementierung doch recht spärlich ausfällt.
"Einige marktführende Unternehmen" => Microsoft.
Das erklärt auch, warum niemand aus der Open-Source-Welt für deren Spec Bibliotheken entwickeln will, und warum außer für MS- und generelles Enterprise-Zeugs (Java, .NET, C#) auf der OData-Seite keine Libs zu finden sind.
Wie gesagt: Wenn du gegen so einen Service entwickeln musst: Mein Beileid.
Wenn du hingegen der Service bist: Stattdessen Zend's Apigility angucken.
- Sven Rautenberg