- From: David A. Lee <dlee@calldei.com>
- Date: Tue, 23 Dec 2008 08:04:16 -0500
- To: "Norman Walsh" <ndw@nwalsh.com>, "XProc Dev" <xproc-dev@w3.org>
--- Quoteth Norm I see where you're going, but I think the WG has consensus that the p:http-request step should be a fairly rich step. I also think there's a natural answer to the questions you pose: the step should be media type agnostic. So cookies are in, Java, ActiveX Controls, etc. are out. ---- Would this then become a requirement ? or a vendor implementation decision ? Cookies are particularly problematic because to fully implement them requires state. That is they may have an expiration way into the future (1 year is not uncommon), so you'd need to keep a cookie cache around and also document the side effects. http-request would then become stateful. Its functionality could depend on previous calls either in the same pipeline, same xproc "session" or previous incarnations/runs of the system. Then you'll need to expose a way to "clean" the cookie cache, or parts of it. I personally want to stay way away from that slipperly slop. There's existing tools out there that handle this and they are non-trivial. Any trivial implementation will fail in non-deterministic or implmentation-dependant ways, which is worse, IMHO, the not handling cookies at all. If this becomes a spec requirement then you've got a lot of paragraphs to write. You'll need to define what subset (if any) of the Cookie specs are required, what are optional and what the behaviour would be if the optional parts are omitted. -David ----------------------------------------------------------- David A. Lee dlee@calldei.com http://www.calldei.com
Received on Tuesday, 23 December 2008 13:05:00 UTC