Entwerfen für EWGI-Kompatibilität

Question

Ich versuche zu verstehen, wie man Middlewares für EWGI Kompatibilität entwerfen sollte. Da es noch keinen EWGI-konformen Webserver gibt, kann ich nur nach Ihrer Meinung fragen.

Wenn ich die Spezifikation verstehe. richtigerweise empfängt eine Middleware einen #ewgi_context {} - Datensatz als Eingabe und gibt einen anderen Datensatz desselben Typs zurück.

Frage ist, wird die Middleware zweimal aufgerufen wie in django, oder soll es den Rest der Middlewares rekursiv selbst nennen?

Gibt es auch eine vorgeschlagene Möglichkeit für eine Middleware, den Rest der Middlewares zu benachrichtigen, dass das Ergebnis angeblich die endgültige Antwort ist? (Wenn beispielsweise die File-Serving-Middleware eine Datei gefunden hat, ist es nicht sinnvoll, die View-Middleware aufzurufen). Als Ergebnis meiner Ansicht ist eine Kontextaufzeichnung, wie sollte der Rest der Middlewares (oder der Server) herausfinden, dass es die endgültige Antwort ist?

Answer 1

Da gibt es keinen EWGI konformen Web-Server noch, ich nur für Ihre Meinung frage

Es gibt keine Notwendigkeit EWGI konformer Web-Server zu existieren, weil es die Rolle der EWGI ist, den Zugang zu vereinen und von verschiedenen Webservern. Das ist die Kernidee von EWGI.

Auf der anderen Seite, wenn Sie "EWGI-konformes Web-Framework" gemeint haben, gibt es tatsächlich zwei (oder mehr?) Web-Frameworks, die EWGI unterstützen. Dies sind Erlang Web und BeepBeep.

oder soll es den Rest der Middlewares rekursiv selbst aufrufen?

Die Middlewares sollen sich gegenseitig rekursiv aufrufen, also ist es die Rolle der Middleware, zu entscheiden, was als nächstes zu tun ist.

Auch gibt es eine vorgeschlagene Weg für eine Middleware den Rest der Middle zu informieren, dass das Ergebnis ist angeblich die endgültige Antwort

Ihre letzte Frage zu beantworten, ich denke, dass da Middle jeden Anruf anders rekursiv wäre der einfachste Weg, dies zu erreichen, nicht andere Middlewares aufzurufen, wenn die Antwort endgültig ist, und #ewgi_context {} record auf die ewgi-Ebene zurückzugeben.

Answer 2

Middleware kann je nach Situation sowohl den iterativen als auch den rekursiven Ansatz verwenden.

Ein Beispiel für den iterativen Ansatz ist:

http://groups.google.com/group/ewgi/browse_thread/thread/f9042018cb27baa3

Andere einfache Beispiele sind in ewgi_examples

Im Allgemeinen mir den iterativen Ansatz bevorzugen, aber wenn Sie Sie haben eine Middleware, die auf anderen hängt der rekursive Ansatz ist wahrscheinlich besser.

Gibt es auch eine vorgeschlagene Möglichkeit für eine Middleware, den Rest der Middlewares zu benachrichtigen, dass das Ergebnis angeblich die endgültige Antwort ist? (Wenn beispielsweise die File-Serving-Middleware eine Datei gefunden hat, ist es nicht sinnvoll, die View-Middleware aufzurufen).Als Ergebnis meiner Ansicht ist eine Kontextaufzeichnung, wie sollte der Rest der Middlewares (oder der Server) herausfinden, dass es die endgültige Antwort ist?

Es gibt keine vorgeschlagene Möglichkeit. Wenn Sie den rekursiven Ansatz als wahnsinnig beantwortet verwenden, müssen Sie nur den ewgi_context zurückgeben. Beim iterativen Ansatz könnte die Ansicht oder der Aufrufer der Ansicht prüfen, ob der Antworttext und die Header im ewgi_context festgelegt sind und entscheiden, was entsprechend zu tun ist.

Im Allgemeinen denke ich an Ewgi als Unix-Rohre für das Web. Jede Middleware erhält eine Anfrage und Antwort (ähnlich wie stdin und stdout in Pipes). Sie erledigt ihren Job, um den Kontext zu ändern (falls nötig) und gibt ihn zurück.

Hoffe, das hilft.