Opened by rosti at 2018-12-27 19:58
User since
2011-03-19
3472 Artikel
BenutzerIn
![[Homepage]](/battie/theme/default/homepage.gif)
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
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)
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)