Microservices Artikel auf heise (sonstige Sprachen, auch PHP)

[thread]20065[/thread]

Microservices Artikel auf heise

Leser: 16

Articles: hide open all | hide show old branches

+20 replies
lichtkind

2016-05-01 23:24

User since
2004-03-22
5679 Artikel
ModeratorIn + EditorIn

http://www.heise.de/developer/artikel/Microservice...

Also wenn ich das richtig verstehe hat er das wunder von sorgfältig konzipuerten subroutinen /API neu entdeckt?
Tutorien in der Wiki, mein zeug:
kephra, baumhaus, garten, gezwitscher

Es beginnt immer mit einer Entscheidung.
- Muffi
  
  2016-05-02 09:35
  
  User since
  2012-07-18
  1465 Artikel
  BenutzerIn
  
  ich glaub mit seinen Services meint er schon noch mehr als nur subroutinen.
  1 + 1 = 10
- +11 replies
- Gast wer
  
  2016-05-02 11:18
  
  ja und nein.
  
  Die Idee die er vermittelt ist das ein Programmierer ein oder ein paar "Fähigkeiten" Services eines Systems verwaltet und pflegt. Alle anderen Programmierer haben nur einen einen groben Überblick welche Services es gibt und was die können. Wird eine Aktion oder Information gebraucht wendet man sich an die Person die einen Passenden Service pflegt, welche dann mitteilt wie genau man das erreicht oder diese Funktionalität implementiert.
  
  Wie genau die Services implementiert sind hat er nicht erwähnt. Die Beschreibung deutet auf Netzwerkservices.
  
  Und das zeigt auch auf warum er das ganze für so "Ausfallssicher" hält.
  
  Netzwerk IPC Protokolle wie SOAP oder ähnliches sind so konzipiert das sie Ausfälle des Services abfangen können. Das hat zur Folge das ein Zugriff auf einen Defekten Service nicht zu einem Totalausfall führt sondern zu einer Fehlerbehandlung.
  
  Das ist Auch anders als über einen Netzwerkservice zu bewerkstelligen. Nur sind Netzwerkservices ein einfacher weg dies umzusetzen da alle wichtigen Funktionalitäten schon vorhanden sind.
  
  Ich mache da aber ein paar Einschränkungen.
  So ist es Durch aus möglich das der Ausfall eines Zentralen Services das ganze System zum Zusammenbruch bringt, wenn die Services nicht "fein" genug gliedert sind. Viele Programmiersprachen können auch zu Problemen führen. Die Kommunikation produziert einen großen Overhead, der bei großen Datenmengen zu Problemen führen kann.
  
  Es ist nicht ganz so rosig wie er es beschreibt.
  Aber ja: String-eval (Neue Interpreter Instanz) und Errorhandling kann ein System zuverlässiger machen. ;-)
  Last edited: 2016-05-02 12:16:27 +0200 (CEST)
  - +3 replies
  - lichtkind
    
    2016-05-02 12:19
    
    User since
    2004-03-22
    5679 Artikel
    ModeratorIn + EditorIn
    
    klar ist ein microservice mehr und er hat seinen overhead an pflege etc.
    
    Aber was ich hier rauslese ist eigentlich etwas das man normalerweise auch innerhalb einer normalen codebase erreichen kann. nur da hält sich kaum jemand dran, weil copy paste so schnell und einfach ist und beim microservice halt nicht. das sind künstlich stacheldrahtumwehrte zäune die wänster dazu zwingen api zu verwenden und wiederzuverwenden.
    Last edited: 2016-05-03 01:05:00 +0200 (CEST)
    Tutorien in der Wiki, mein zeug:
    kephra, baumhaus, garten, gezwitscher
    
    Es beginnt immer mit einer Entscheidung.
    - Gast wer
      
      2016-05-02 13:12
      
      Ja die Verwendung von Webservices zwingt einen dazu "sauber" zu arbeiten. Da die Schnittstelle streng ist und es keine einfache Möglichkeit gibt sie zu umgehen oder zu modifizieren.
      
      So ist z.B SOAP nur ein Mittel zum Zweck.
      
      Mit genügend Kontrolle und Disziplin ist das auch anders zu erreichen.
      Last edited: 2016-05-02 13:21:10 +0200 (CEST)
    - jan
      
      2016-05-02 14:25
      
      User since
      2003-08-04
      2536 Artikel
      ModeratorIn
      
      In Teilen, ja.
      Ich verstehe es eher dahingehend, dass "vieles" läuft, auch wenn irgendein Teil mal kaputt ist. Bei einer einzelnen großen Anwendung hat man da schneller das Problem, dass dann gar nichts mehr geht. Da ist dann nichts mehr "too big to fail".
      
      Und auch die Komplexitätsüberlegung finde ich nicht verkehrt. Natürlich, ein paar ewige Besserwisser bei heise echauffieren sich in den Kommentaren, dass gar keine Komplexität verschwindet, sondern nur ignoriert wird, aber die Idee ist bestechend.
      Bei einem wirklich großen System ist es illusorisch, anzunehmen, dass wirklich jemand alle Komponenten versteht. Schön ist es, wenn jemand einen groben Überblick hat, aber mehr ist nicht zu erwarten. Quasi wie beim geographischen Äquivalent: Du wirst dich schon in Deutschland niemals regional überall auskennen. Und Du musst es auch nicht, Du musst nur die Umgebung kennen, in der Du dich bewegst. Wenn Du dazu noch ungefähr weißt, wo die Berge und das Meer sind, ist schon einiges gewonnen. Und falls Du mal in einer dir unbekannten Region bist, suchst Du dir jemanden, der sich dort auskennt und dich führt.
  - +7 replies
  - Muffi
    
    2016-05-02 16:51
    
    User since
    2012-07-18
    1465 Artikel
    BenutzerIn
    
    Wegen Ausfallsicherheit:
    
    Da gibt's eine ganz nette Frage meines Luftfahrt-Profs von damals.
    "Was glauben sie was sicherer ist, eine 1-Motorige oder eine 2-Motorige Chesna?"
    Die Antwort schien klar, natürlich die 2-Motorige.
    
    Die Antwort des Profs:
    Warum fällt was aus? In den Allermeisten Fällen bei folgenden 2 Situationen:
    - Sprit alle (da helfen 2 Motoren nix)
    - Beim Start wenn die Maschine noch nicht lang läuft. (da sind 2 Motoren sogar schädlich, da dann bei Vollgas nur noch ein Motor sehr außermittig läuft und ein extrem ekliges Moment erzeugt. Mit großer Gefahr, dass eine Tragfläche auf den Moden schlägt.
    Lieber garnix mehr haben und zurück zum Boden segeln.
    
    Schlussendlich ist natürlich auch die Wahrscheinlichkeit, dass ein Motor ausfällt bei 2 höher als bei einem.
    
    Und jetzt auf die IT übertragen: Keep it simple.
    Laut meinem Bauchgefühl (was aber auch trügen kann) sind mehr Sachen in meinem IT-Leben durch Redundanzsysteme ausgefallen, als durch wirkliche Defekte. Oder im Fall eines Defekts war das Redundanzsystem nutzlos.
    
    Ob die Geschichte von damals nun wirklich bewiesen ist oder auch nur persönliche Meinung des Profs - keine Ahnung.
    Aber es schadet nichts sich immer mal wieder die Frage zu stellen: Wird's dadurch wirklich ausfallsicherer oder nur komplizierter.
    Last edited: 2016-05-02 16:58:21 +0200 (CEST)
    1 + 1 = 10
    - +6 replies
    - jan
      
      2016-05-02 18:29
      
      User since
      2003-08-04
      2536 Artikel
      ModeratorIn
      
      Wobei ich glaube, man kann das Flugzeugbeispiel nicht wirklich übertragen ... denn ich glaube durchaus, dass es besser ist, wenn NUR die Anmeldefunktion ausfällt, aber die Webseite selbst noch läuft als dass alles weg ist ;)
      - +5 replies
      - Muffi
        
        2016-05-02 20:32
        
        User since
        2012-07-18
        1465 Artikel
        BenutzerIn
        
        Ja und nein. Und ich bin auch nicht gegen Redundanz, aber nicht alles was so verkauft wird machts auch besser.
        
        Nehmen wir dein Beispiel: Vorher musste die Webseite ausfallen. Jetzt reichts wenn Anmeldefunktion ODER Webseite ausfallen.
        Und selbst wenn du schon angemeldet bist hab ich schon erlebt, dass das kaputte eine System sowas wie einen DOS am anderen ausgelöst hat womit beide tot waren. Also konkret gingen dem Apache innerhalb kürzester Zeit die Prozesse aus.
        Last edited: 2016-05-02 20:36:01 +0200 (CEST)
        1 + 1 = 10
        
        +4 replies
        
        jan
        
        2016-05-04 08:21
        
        User since
        2003-08-04
        2536 Artikel
        ModeratorIn
        
        Vollkommen einverstanden, dass Verkäufer oft verkaufen und wenig von dem stimmt, was sie sagen (wie in der Politik).
        Aber das sind ja nicht zwingend wirkliche Probleme der Theorie, sondern nur zu hohe (geweckte) Erwartungen. ;)
        
        +3 replies
        
        Gast janus
        
        2016-05-04 08:36
        
        Ja, wer über plattformübergreifende und programmiersprachenunabhängige Services schreibt, sollte zumindest den Begriff "Serialisierung" wenigstens mal irgendwo gehört haben. Vielleicht sogar auch selbst gelesen ;)
        Last edited: 2016-05-04 09:17:44 +0200 (CEST)
        
        +2 replies
        
        jan
        
        2016-05-04 10:59
        
        User since
        2003-08-04
        2536 Artikel
        ModeratorIn
        
        Selbst wenn's alles die selbe Plattform ist und alles die selbe Programmiersprache, finde ich Kapselung gut. Wie bei einem Schiff, wo dafür sorgt, dass bei einem Leck nicht der ganze Schiffsrumpf vollläuft, sondern nur ein Kompartment und das ganze Ding eher schwimmfähig bleibt. Klar, kostet mehr und solange nichts passiert ist es "unnötiger" overhead, aber beim ersten Leck macht es sich auf einen Schlag mehr als bezahlt ;)
        
        Gast janus
        
        2016-05-04 15:51
        
        Eine flache Klassenhierarchie, alles erbt von der main.
        Und Methoden in eine Factory auslagern:
        
        1. Nicht verwandte Klassen werden erst zur Laufzeit und nur bei Bedarf kompiliert
        2. Instanzen nicht verwandter Klassen bleiben verborgen
        3. Code Reduzierung
        4. keine Code Redundanzen
        5. testgetriebene Entwicklung (Aufruf der Methode via Mock)
        6. Teamarbeit
        7. Austauschbare Data Access Layer
        mehr Durchblick.....
        
        D.h., per AUTOLAOD werden nicht Klassen sondern Methoden geladen, die jedoch bei Bedarf weitere Klassen einbinden. Und wenn AUTOLOAD bereits in der main definiert ist, stehen alle Methoden der Factory auch den Subklassen zur Verfügung. Deswegen können die ja auch gemockt werden.
        
        Typisches Beispiel:
        
        http://perl.rolfrost.de/notes.html?show=32
        
        macht auch den Vorteil deutlich, ein Template unterhalb __DATA__ in die Funktion einzubauen.
        Last edited: 2016-05-04 16:18:14 +0200 (CEST)
- +7 replies
- Gast janus
  
  2016-05-02 22:40
  
  PL bzw. Plattformübergreifend heißt für mich , dass Daten den Hauptspeicher verlassen müssen. XML, SOAP, JSON, multipart/form-data und all der andere Schrott ungezählt grottiger Content-Types fällt mir dazu ein.
  
  Selbst der Fakt, das mittlerweile (seit Jahren!) JavaScript mit reinen Binaries umgehen kann, scheint vielen Entwicklern glatt am Arsch vorbeizugehen. Oder hab ich da was verpasst kurz bevor ich in Rente ging!?
  Last edited: 2016-05-03 01:02:21 +0200 (CEST)
  - +6 replies
  - renee
    
    2016-05-03 05:37
    
    User since
    2003-08-04
    14371 Artikel
    ModeratorIn
    
    Nicht immer ist der Client einer API in JavaScript geschrieben! Deswegen nimmt man ein Format das die unterschiedlichsten Sprachen verstehen. Und wenn man ein gängiges Format gibt, gibt's auch schon Bibliotheken in den verschiedensten Sprachen dafür.
    
    Und für die Formate gibt es häufig dann auch "Spezifikationen" (JSONAPI, HAL, OData, ...) die eine Schnittstelle Anwendungsunabhängig beschreiben was das Testen, Entwickeln und Nutzen einfacher macht. Vor allem wenn man mit APIs arbeitet, die man nicht selbst unter Kontrolle hat. Dann heißt es nur "Wir sind OData-Konform" und man kann als Entwickler schon direkt was anfangen, ohne dass man den Herstellerspezifischen Mist lernen muss - der dann im nächsten Release wahrscheinlich wieder ganz anders aussieht.
    
    Und auch sonst ist manchmal ein menschenlesbares Format auch nicht schlecht (Debugging, Requests mal eben auf der Konsole absetzen, ...)
    Last edited: 2016-05-03 05:42:05 +0200 (CEST)
    OTRS-Erweiterungen (http://feature-addons.de/)
    Frankfurt Perlmongers (http://frankfurt.pm/)
    --
    
    Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
    Perl-Entwicklung: http://perl-services.de/
    - +5 replies
    - Gast janus
      
      2016-05-03 07:48
      
      Das Wichtigste ist beim Serialisieren, den dazu passenden abstrakten Datentyp zu finden. Interessant sind da vor Allem zyklische Strukturen, beispielsweise als ein langkettiger Hash of Hashes. Darin steckt das Muster Entity-Attribute-Value (EAV) und auch eine gewöhnliche INI-Datei ist danach aufgebaut:
      
      Code: (dl )
      
      1 2
      
      [Entity] Attribute = Value
      
      Natürlich haben INI-Dateien hinsichtlich Performance ihre Grenzen, aber anderweitig serialisiert ist es für Perl kein Problem, Dateien mit einigen tausend Rekords bei jedem HTTP-Request von der Platte zu lesen. So richtig interessant wird das bei mod_perl oder FastCGI, bspw. für eine Speicherresidente Configuration. Das EAV-Pattern ergibt einheitliche Prozesse für den Zugriff:
      
      Code (perl): (dl )
      
      1 2
      
      $title = $self->eav('title'); # Getter $self->eav('title', 'Neuer Titel'); # Setter
      
      und vor Allem macht ein zweckmäßiges Daten-Entwurfsmuster rekursive Serializer überflüssig. Nicht zuletzt kann aus jedem gewöhlichen Array ein assoziatives Array und abstrakt gesehen eine beliebige Struktur erzeugt werden und wer hätte das gedacht: solche Transformationen sind Plattformunabhängig. Z.B. ergeben nicht nur 2 Array-Werte einen Record sonden auch mal 3 oder 4 oder 5 oder... wobei wir mit 3 Werten wieder bei EAV sind $data = { Entity => { Attribute => 'Value' }}
      
      Last but not least: Tabellen mit beliebig vielen Spalten lassen sich unter der Voraussetzung dass es nur einen unique Key gibt, ebenfalls auf EAV abbilden. Auf diese Art und Weise werden Anwendungen vom DB-Design unabhängig, allein die Anwendung bestimmt die zum Speichern erforderliche Datenstruktur. Data Acces Layer werden dadurch austauschbar und das mit extrem geringem Zeitaufwand.
      
      Fazit: Serilize Algorithmen sind PL und plattformunabhängig und ob JSON, XML oder sonstwas draus gemacht wird, ist absolut nebensächlich. Viel wichtiger ist die Einigung auf einen bestimmten abstrakten Datentyp.
      
      Letztes Beispiel RPC:
      
      Code: (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13 14
      
      D:\>.pl RPC Remote CMD auf dem Host --attribute, -a: Zeigt Attribut+Value einer Entity in Konfiguration --base, -ba: Name der Datenbank für Option --sql --binary, -bi: Erzeuge die Konfiguration als Binary --cmd, -c: Freies Kommando im aktuellen Verzeichnis --dump, -d: Dump Response Object --entity, -e: Zeigt Attribute einer Entity in Konfiguration --files, -f: Lokale Dateien für Upload --head, -he: HEAD Request auf URL --host, -ho: example.com --request, -r: HTTP Request auf den angegebenen URL oder auf alle URLs --sql, -s: SQL Anweisung String oder Datei, erfordert --base --urls, -u: Listet URLs in Konfiguration
      
      Dem Serverseitigen Parser wird lediglich der Content-Type für den POST mitgeteilt. Die daraus erzeugte Datenstruktur ist stets dieselbe. Also egal ob multipart/form-data, application/json, application/xml, application/eav-binary... für mich war die Integration eines Kommandozeilen Framework in mein Web-Application Framework letztendlich ausschlaggebend dafür, die Verwendung von CGI.pm endgültig zu streichen.
      Last edited: 2016-05-03 08:22:09 +0200 (CEST)
      - +4 replies
      - renee
        
        2016-05-03 10:42
        
        User since
        2003-08-04
        14371 Artikel
        ModeratorIn
        
        Was hat dieser Post mit dem Thema "eigenes binärformat" vs. JSON/XML/... als Datenaustauschformat zu tun? Was Du beschrieben hast ist doch vollkommen unabhängig davon welches Format dann für die Übertragung von Daten genommen wird.
        
        Dein Ini-Beispiel wäre mit JSON einfach {"Entity":{"Attribute":"Value"}}.
        
        Und wenn die Config bei Start des Prozesses gelesen wird ist es unerheblich, ob ich eine .ini parsen muss oder eine .json. Selbst wenn das Parsen von .json etwas länger dauern sollte (wobei Du ja schreibst, dass .ini-Dateien Grenzen bei der Performanz haben) - und da würde es in der Regel wohl eher um hunderstel oder zehntel Sekunden gehen, würde das einmal gemacht werden und danach bleiben die Infos im Speicher.
        
        Wie Du schon sagst, kommt es auf die Datenstruktur an sich an.
        
        Zu Deinem letzten Punkt, Du kannst auch mit CGI.pm auf verschiedene Formate - sowohl in Richtung Anwendung als auch Richtung Client - reagieren... Dafür gibt es die HTTP-Header ja...
        
        Und was das Kommandozeilen-Tool angeht: Bei Mojolicious gibt es ojo, damit man schnell auf der Kommandozeile etwas machen kann.
        OTRS-Erweiterungen (http://feature-addons.de/)
        Frankfurt Perlmongers (http://frankfurt.pm/)
        --
        
        Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
        Perl-Entwicklung: http://perl-services.de/
        
        +3 replies
        
        Gast janus
        
        2016-05-03 11:43
        
        Natürlich kann PHP nicht auf das zugreifen, was Perl in den Hauptspeicher geladen hat. Bei einem Web-Application-Framework, was sowohl mit Perl als auch mit PHP funktionieren soll, muss daher bereits am Webserver anhand des Request entschieden werden, ob PHP oder Perl für die Response zuständig ist, was ja auch problemlos konfigurierbar ist.
        
        Und wenn die Seiten alle gleich aussehen sollen, muss es einen gemeinsamen Nenner für die Konfiguration geben, sprich: Eine Datei die mit demselben Algorithmus eingelesen wird. D.h., praktisch muss in Perl und in PHP derselbe abstrakte Datentyp verwendet werden.
        
        Es gibt immer genau dann ein Problem, wenn es Abweichungen in der Abstraktion der Datentypen gibt. Problematisch ist z.B. bereits die Serverumgebung, in Perl wie in PHP fast gleich aber es gibt eine Abweichung:
        
        Code: (dl )
        
        1 2 3 4 5 6 7
        
        [REQUEST_TIME] => 1462266830 [argv] => Array ( [0] => C:\Dokumente und Einstellungen\rolf\Desktop\pack.php ) [argc] => 1
        
        Und jetzt mal was Anderes: An meiner Idee für einem universellen Parser, der um beliebige Content-Types (im Client als Enctype bezeichnet) erweiterbar ist, habe ich lange gearbeitet, nicht zuletzt auch wegen meiner Erkrankung hat das viel Zeit gebraucht. Umsetzen kann das jeder halbwegs begabte Programmierer, genauso wie meine Frameworks: Entscheidend ist nicht das bischen Code sondern immer die Idee.
        
        Es ist unerheblich wie Daten serialisiert werden und dass XML oder JSON plattformunabhängig sind ist deswegen auch eine unsinnige Behauptung, eben weil sich jeder beliebige Serialize-Algorithmus mit jeder beliebigen Programmiersprache auf jeder beliebigen Plattform umsetzen lässt. Entscheidend ist die Einigung auf einen einheitlichen abtrakten Datentyp und so ist es auch mit ein bischen Übung überhaupt kein Problem eine MIME-Mail auf EAV abzubilden weil eine MIME-Mail genauso eine zyklische Datenstruktur abstahiert wie das Muster Entity-Attribute-Value. Dasselbe gilt für multipart/form-data und solche Beispiele lassen sich beliebig fortführen. Bis zu dem Moment, wo ein Entwickler auf die Idee kommt, Literale durch Referenzen ersetzen zu müssen, siehe obenstehend $_SERVER vs. %ENV.
        
        So braucht XML-RPC keineswegs XML um die Daten zu verpacken, aber das nurmal so nebenbei bemerkt. Der Hack bei meinen Frameworks besteht darin, dass Remote-Prozeduren genauso von einer serverseitigen Framework-Instanz ausgeführt werden wie gewöhnliche Requests, was eine nahtlose Integration des Kommandozeilen-Framework in das Web-Application-Framework bedeutet: Es ist derselbe Code und es sind dieselben Libraries und die FW-Instanz hat Vollzugriff auf alle persistenten Daten wie die Konfigurtion und überhaupt den gesamten Content, egal ob im Dateisystem oder in MySQL.
        
        In diesem Zusammenhang einen zweckmäßigen Ersatz für CGI.pm zu finden ist da eher ein gesetzmäßiger Vorgang. Untenstehend meine bisherige Controllstruktur:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
        
        # hier werden die jeweiligen Layer geladen sub _parse_rawdata{ my $self = shift; if( $self->{CONTENT_TYPE} eq 'multipart/c-eav' ){ require cEAV; $self->{eav} = cEAV->decode_eav( $self->rawdata ); $self->{param} = $self->{eav}->{param}; } elsif( $self->{CONTENT_TYPE} eq 'multipart/eav' ){ # coming soon } elsif( $self->{CONTENT_TYPE} eq 'multipart/form-data' ){ require ParseMultipart; $self->{STDIN}->seek(0,0); $self->{param} = ParseMultipart->parse_multipart( $self->{STDIN} ); } elsif( $self->{CONTENT_TYPE} eq 'application/json' ){ require JSON; my $json = JSON->new; $self->{json} = $json->decode($self->rawdata); $self->{param} = $self->{json}{param}; } elsif( $self->{CONTENT_TYPE} eq 'bserialize/av' ){ require bSerialize; my $bs = bSerialize->new; my $binary = $self->rawdata; $self->{param} = $bs->bin2av( \$binary ); } else{ # Default Enctype # Parameter: Name => [Value], application/x-www-form-urlencoded $self->{param} = $self->qparse($self->rawdata); } }
        
        Last edited: 2016-05-03 11:57:58 +0200 (CEST)
        
        +2 replies
        
        renee
        
        2016-05-03 14:46
        
        User since
        2003-08-04
        14371 Artikel
        ModeratorIn
        
        Guest janus
        Und jetzt mal was Anderes: An meiner Idee für einem universellen Parser, der um beliebige Content-Types (im Client als Enctype bezeichnet) erweiterbar ist, habe ich lange gearbeitet, nicht zuletzt auch wegen meiner Erkrankung hat das viel Zeit gebraucht. Umsetzen kann das jeder halbwegs begabte Programmierer, genauso wie meine Frameworks: Entscheidend ist nicht das bischen Code sondern immer die Idee.
        ... die auch nicht so neu ist. Das nennt sich Content-Negotiation und ist z.B. hier beschrieben: http://www.programmableweb.com/news/rest-api-desig...
        
        Guest janus
        Es ist unerheblich wie Daten serialisiert werden
        sag ich ja
        
        Guest janus
        und dass XML oder JSON plattformunabhängig sind ist deswegen auch eine unsinnige Behauptung, eben weil sich jeder beliebige Serialize-Algorithmus mit jeder beliebigen Programmiersprache auf jeder beliebigen Plattform umsetzen lässt.
        Hier widersprichst Du Dir in einem Satz...
        
        Guest janus
        PL bzw. Plattformübergreifend heißt für mich , dass Daten den Hauptspeicher verlassen müssen. XML, SOAP, JSON, multipart/form-data und all der andere Schrott ungezählt grottiger Content-Types fällt mir dazu ein.
        Was mir immer noch nicht klar ist: Warum sind XML, JSON etc. grottig?
        
        Guest janus
        Selbst der Fakt, das mittlerweile (seit Jahren!) JavaScript mit reinen Binaries umgehen kann, scheint vielen Entwicklern glatt am Arsch vorbeizugehen. Oder hab ich da was verpasst kurz bevor ich in Rente ging!?
        Warum sollte ich "mit reinen Binaries" etwas umsetzen? Das hast Du in den vergangenen Posts noch nicht erklärt - Du hast immer nur davon gesprochen, dass Dein Framework eben auch JSON, XML, ... behandeln kann.
        OTRS-Erweiterungen (http://feature-addons.de/)
        Frankfurt Perlmongers (http://frankfurt.pm/)
        --
        
        Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
        Perl-Entwicklung: http://perl-services.de/
        
        Gast janus
        
        2016-05-03 15:53
        
        Die Kontrollstruktur meines hier vorgestellten Parsers zeigt die Unabhängigkeit vom gesendeten Enctype. Wobei es natürlich wenig sinnvoll ist, bei der Übertragung von Text auf application/json umzuschalten. Das ganze Geheimnis eines binary safe Serialize-Algorithm besteht darin, mittels pack() die Längenangaben von Werten auf einheitlich 4 Byte zu bringen. D.h., die kleinste Einheit wäre pack("N", $value).$value wobei nur noch festzulegen wäre, wie mit undef vs. Leerstrings umgegangen werden soll.
        
        Entweder über ein zusätzliches Byte oder eine Vereinbarung like NOT NULL. Ansonsten liefert $self->param('name') immer dasselbe egal ob POST, GET, PUT oder eine andere exotische Requestmethode und auch egal, welcher Enctype vom Client benutzt wird.
        
        Zweifellos grottig ist der Enctype multipart/form-data, insbesondere ist die Verwendung einer Boundary mehr als umständlich innerhalb einer auf die Verarbeitung von Bytes ausgerichtetetn Programmierung. Viel effizienter ist es, mit Längenangaben zu arbeiten, das vereinfacht den Parser und macht die Boundary gar überflüssig:
        
        Mit Längenangabe: Der Parser liest bytegenau die Binary aus der Gesamtsequenz, fertig.
        Mit Boundary: Der Parser muss byteweise durch die Sequenz gehen solange bis die Boundary erkannt wurde und muss danach die Boundary wieder abschneiden.
        
        Und überhaupt sind zeichenorientierte "Verpackungen" ineffizient, den in PHP üblichen Serialize-Algorithmus, der auch als CPAN-Modul zu haben ist, habe ich mal mit anderen Serializern verglichen, er schneidet von allen als Schlechtester ab.
        
        Im Übrigen hat kein Geringerer als Niklas Wirth bereits um 1980 darauf hingewiesen, dass Random Access (Wahlfreier Zugriff) nicht in einer Byte-Sequenz sondern im Hauptspeicher abgebildet wird. Zwischen Beiden vermittelt ein Algorithmus.
        
        PS: Mein Content Management bis hin zum Remote DB-Management mach ich schon seit Jahrzehnten über HTTP/Webservices und Perl auf Beiden Seiten. Auf die Idee, eigene Serializer zu bauen, bin ich zwangsläufig gekommen, nachdem ich feststellen musste dass Storable::freeze/thaw Kompatibilitätsprobleme hat und ich mich von daher nicht darauf verlassen kann, dass Daten auf verschiedenen Plattformen/Perlversionen fehlerfrei wiederhergestellt werden können.
        Last edited: 2016-05-03 17:20:05 +0200 (CEST)

View all threads created 2016-05-01 23:24.