Perl WebFramework nun auch in c (Projekte)

[thread]20554[/thread]

Perl WebFramework nun auch in c

Leser: 18

Articles: hide open all | hide show old branches

+7 replies
rosti

2018-12-27 19:58
User since
2011-03-19
3472 Artikel
BenutzerIn
Hab die letzten Tage dran gearbeitet: Mein WebApplikation Framework funktioniert nun auch in c. D.h., das FW als ausführbare Datei ist in c geschrieben. Untenstehende .htaccess
Code: (dl )

1 2 3 4

RewriteRule \.(htm)$ /cgi-bin/a.exe [L] RewriteRule ^program$ /cgi-bin/a.exe [L] RewriteRule ^framework.html$ /cgi-bin/a.exe [L] RewriteRule !\.(exe|mp3|gz|ppd|wav|zip|cgi|css|jpg|js|gif|ico|pac|png|appcache|htm|bin|pdf|nph)$ /cgi-bin/fwdbf.cgi [L]
zeigt das wie des Nebeneinander. Es werden also Gruppen von URLs oder einzelne URLs entweder auf c oder auf Perl umgeschossen. Sofern die Templates kompatibel zu HTML::Template sind, ist da kein Unterschied zu sehen. Außer die Performance, die hat selbst mich überrascht: Die Seiten über das c-Framework werden um ein vielfaches schneller ausgeliefert als Perl. Also so schnell als würde das gar nicht über die CI-Schnittstelle laufen und der Apache die Seiten selbst ausliefern. Und die main hat ganze 20 Zeilen...

Die Konfiguration + Routingtable liegt in einer Binärdatei (zZ. 1.5 MB) die mit Perl und c gleichermaßen gelesen und bei jedem Request in den Hauptspeicher geladen wird.

In mod_perl oder FastCGI wird diese Datei beim Serverstart in den RAM gelesen, das ist einer der wesentlichen Unterschiede. Über den ParameterParser in c muß ich noch nachdenken. Der derzeitige Stand ermöglicht aber schon die Platzhalter, die TE ctemplate.c (https://github.com/ac000/libctemplate) habe ich gleich mit einbezogen weil die Templates kompatibel zu HTML::Template sind.

PS:

Deployment: Die Binary Datei für Konfiguration + Routingtable wird mit Perl erzeugt und bearbeitet. Der Einbau einer neuen Webressource erfolgt serverseitig, die lokale HTML Datei wird per RPC zum Server übertragen und dort in die Binary eingebaut. Diese Binary ist praktisch in jeder Programmiersprache lesbar, auch in PHP und selbstverständlich auch in JavaScript. Mit XML ist sowas nicht machbar und das Argument, daß XML plattformübergreifend maschinenlesbar sein soll war schon immer ein Witz.

Wenn Dateien plattformübergreifend und maschinenlesbar lesbar sind, dann sind das meine Binärdateien. Diesbezüglich eigens entwickelte Algorithmen beschreibe ich auch auf meiner Website. Meine Serializer machen den Transportlayer (HTTP) für Client Server Anwendungen (AJAX) binary safe und transparent: Client wie serverseitig sind es dieselben Datenstrukturen, die letztendlich auch ein Famework über mehrere Programiersprachen ermöglichen, in Perl, c und PHP.

Und ich bin überzeugt davon daß mein Framework auch in Java, Python und weiteren PLs machbar ist.

.
Last edited: 2018-12-28 09:20:33 +0100 (CET)
- +2 replies
- Gustl
  
  2018-12-28 12:46
  
  User since
  2011-01-27
  441 Artikel
  BenutzerIn
  
  Hallo rosti,
  
  das klingt sehr interessant.
  
  Aber so ganz habe ich das nicht verstanden.
  Du leitest manche Anfragen an dein Framework in Perl und andere an dein Framework welches du in c umgeschrieben hast weiter, richtig?
  
  Wenn aber die main von dem FW in c nur 20 zeilen hat, wie hast du dann das Framework von Perl dort eingebunden?
  Oder rufst du dann in c deinen perl Code mit dem perl interpreter auf?
  
  Vielleicht willst du uns die 20 Zeilen bzw. etwas Code zeigen, damit wir das auch genauer verstehen können? :)
  
  Um welchen Faktor ist es in c dann schneller?
  
  Gruß
  - rosti
    
    2018-12-28 14:09
    User since
    2011-03-19
    3472 Artikel
    BenutzerIn
    
    Quote
    Du leitest manche Anfragen an dein Framework in Perl und andere an dein Framework welches du in c umgeschrieben hast weiter, richtig?
    
    Korrekt. Das passiert in der Serverkonfiguration. Also wird ein Request entweder auf das Perl-FW oder auf das c-FW Rewrited und das völlig unabhängig voneinader.
    
    Genauso wie die Perl main, implementiert die c main nur ein Interface, die c main sieht derzeit so aus:
    
    Code: (dl )
    
    1 2 3 4 5 6 7 8 9 10 11 12 13
    
    int main(){ struct EAV *eav = NULL; readBin(&eav, BINFILE); URL = getenv("REDIRECT_URL") ? getenv("REDIRECT_URL") : "/"; // Interface Funktionen header("Content-Type", "text/html; Charset=UTF-8",1); start_html(eav); menu(eav); bodybuild(eav); end_html(eav); return 0; }
    
    Herzstück also die gemeinsame Konfigurationsdatei BINFILE welche die Routingtable + Konfiguration beinhaltet. Diese Binary wird in c genauso wie in Perl auf eine Entity/Attribute/Value Datenstruktur gelesen, der wahlfreie Zugriff sieht dann z.B. so aus:
    
    Code: (dl )
    
    1 2 3 4 5
    
    in c getVal(eav, URL, "title"); in Perl $responseobject->eav("title");
    
    und so bekommen die Funktionen des Interface den Zugriff auf Alles was für die Response gebraucht wird. Letztere kann, je nach Konfiguration beliebigen Types sein.
    
    Das ist der Plan ;)
    
    PS: Performancegewinn gegenüber Perl: Faktor 10 !
    
    .
    Last edited: 2019-01-02 12:34:24 +0100 (CET)
- rosti
  
  2018-12-29 10:39
  
  User since
  2011-03-19
  3472 Artikel
  BenutzerIn
  
  Herzstück ist die Konfigurationsdatei die mit Perl erzeugt und deployed wird. Wie sie in c gelesen und wie der wahlfreie Zugriff in c erfolgt hab ich hier mal aufgeschrieben: http://rolfrost.de/fwinc.html
  
  MfG
  
  PS1: Beim Entwickeln einundderselben Idee in verschiedenen Programmiersprachen offenbaren sich gelegentlich Fehler die ich dabei in den anderen Programmiersprachen gemacht habe ;)
  
  PS2: Den Parser für den Default Enctype hab ich nun auch fertig. Und gleich erweitert um einen neuen Enctype, der mit JavaScript erzeugt werden kann und plattformunabhängig ist: binary/name+value
  
  Dieser Enctype ermöglicht Uploads ohne den Server zu vergewaltigen oder mit temporären Dateien vollzumüllen!
  
  Aber die Browser sind ja der Entwicklung um Jahre hinterher.
  
  http://rolfrost.de/fwinc.html#parser
  
  .
  Last edited: 2019-12-31 18:07:29 +0100 (CET)
- +3 replies
- rosti
  
  2019-01-19 14:59
  
  User since
  2011-03-19
  3472 Artikel
  BenutzerIn
  
  Sozusagen als Nebeneffekt:
  
  Nameserver-Abfragen mit Perl und mit C
  
  http://rolfrost.de/name.html
  
  Viel Freude damit!
  
  MfG
  - +2 replies
  - kolibri250
    
    2019-01-21 13:32
    
    User since
    2019-01-20
    51 Artikel
    BenutzerIn
    
    2006/2007 herum hatte ich sehr grosse probleme mit den zugriffen auf die datenbanken, wie sich später dann herausgestellt hat durch meine eigene blödheit.. es war null und garnix indexiert.. einerlei..
    
    ich hatte damals versucht, bestimmte, zeitintensive teile einfach in C zu schreiben.. rudimentär, da wenig bis garkein wissen über die sprache vorhanden war..
    
    die datenbankzugriffszeiten im vergleich zum DBI-Paket sind jedoch ein traum! absolut nicht zu vergleichen, daher wundert mich die aussage von rosti garnicht :)
    
    eigentlich ja auch logisch.. gegen vorcompilierte programme haben interpreter nunmal keine chance.. :)
    - rosti
      
      2019-01-21 13:55
      
      User since
      2011-03-19
      3472 Artikel
      BenutzerIn
      
      Ja, DB Anbindung in C ist mein nächstes Thema ;)
      
      Danke für die Erinnerung ;)

View all threads created 2018-12-27 19:58.