That's the word I've been searching for, thank you. Armed with that word, I'll restate. I'd prefer that each step in the "main" WSGI egress pipeline generated a content body that had a structurally isomorphic relationship to the content body generated by the application itself. At least if it wasn't something that caught an exception and turned it into a response (e.g. httpexceptions). That said, I don't a-priori object to non-structurally-isomorphic transforms in the WSGI pipeline, I just prefer to keep them to a minimum in my own pipelines.
I probably shouldn't have mentioned the separate ingress and egress pipelines, it's not very important.
Is client-side XSLT isomorphic?
Posted byzopepaulat
2007-11-20 12:37 PM
The W3C supports a system where you can send text/xml to a browser and, using an XML processing instruction, convert to text/html in the browser. This is supported by IE 5.5+, Mozilla 1.0+, Opera, and Safari.
Is that in the spirit of isomorphism? If so, would doing this same step, but server-side (as Uche's WSGI middleware does) be in the spirit, or against the spirit?
dont know
Posted bychrismat
2007-11-20 06:32 PM
Transforms are useful, so sure, the browser can do them. And it's fine by me if Uche wants to do non-isomorphic transforms using WSGI middleware in his own deployment.
I probably shouldn't have mentioned the separate ingress and egress pipelines, it's not very important.
Is that in the spirit of isomorphism? If so, would doing this same step, but server-side (as Uche's WSGI middleware does) be in the spirit, or against the spirit?