Conception pour la compatibilité EWGI

Question

J'essaie de comprendre comment on devrait concevoir des middlewares pour la compatibilité EWGI. Étant donné qu'il n'y a pas encore de serveur web conforme à EWGI, je ne peux que vous demander votre avis.

Si je comprends la spécification. correctement, un middleware reçoit un enregistrement #ewgi_context {} en entrée et renvoie un autre enregistrement du même type. Est-ce que le middleware va être appelé deux fois comme django, ou est-il supposé appeler le reste des middlewares de façon récursive?

De même, existe-t-il un moyen proposé à un intergiciel d'informer le reste des middlewares que son résultat est supposé être la réponse finale? (par exemple, le middleware de traitement de fichiers frappe un fichier, donc il n'est pas utile d'appeler le middleware de vue). Comme le résultat de mon point de vue est un enregistrement contextuel, comment le reste des middlewares (ou le serveur) devrait-il comprendre que c'est la réponse finale?

Answer 1

Étant donné qu'il n'y a pas EWGI serveur web compatible encore, je ne peux demander votre avis

Il n'y a pas besoin EWGI serveur web compatible existe parce qu'il est le rôle de l'EWGI d'unifier l'accès et de serveur web différent. C'est l'idée de base de l'EWGI. D'un autre côté, si vous vouliez dire «framework web conforme à EWGI», il y a en réalité deux (ou plus?) Frameworks web qui supportent EWGI. Ce sont Erlang Web et BeepBeep. Ou est-il supposé appeler d'une manière récursive le reste des middlewares? Les middlewares sont supposés s'appeler de manière récursive, c'est donc le rôle du middleware de décider de la prochaine étape.

Aussi, est-il un moyen proposé pour un middleware d'informer le reste des intergiciels que son résultat est censé être la réponse finale

Pour répondre à votre dernière question, je pense que parce intergiciels appellent chaque d'autre manière récursive, le moyen le plus simple d'y parvenir serait de ne pas appeler d'autres middlewares si la réponse est finale, et de renvoyer l'enregistrement #ewgi_context {} à la couche ewgi.

Answer 2

Les middlewares peuvent utiliser l'approche itérative ou récursive en fonction de la situation.

Un exemple de l'approche itérative est:

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

D'autres exemples simples sont ewgi_examples

En général, je préfère l'approche itérative, mais si vous vous disposez d'un middleware qui dépend des autres l'approche récursive est probablement meilleure.

De même, existe-t-il un moyen proposé pour un middleware de notifier au reste des middlewares que son résultat est censé être la réponse finale? (par exemple, le middleware de traitement de fichiers frappe un fichier, donc il n'est pas utile d'appeler le middleware de vue).Comme le résultat de mon point de vue est un enregistrement contextuel, comment le reste des middlewares (ou le serveur) devrait-il comprendre que c'est la réponse finale?

Il n'y a aucun moyen proposé. Si vous utilisez l'approche récursive comme une réponse insensée, vous n'avez qu'à retourner le ewgi_context. Dans l'approche itérative, la vue, ou l'appelant de vue, pourrait vérifier si le corps de la réponse et les en-têtes sont définis dans le ewgi_context et décider quoi faire en conséquence.

En général, je pense à ewgi comme unix pour le web. Chaque middleware reçoit une requête et une réponse (similaire à stdin et stdout dans les tuyaux) fait son travail en modifiant le contexte (si nécessaire) et le renvoie.

Espérons que cela aide.