For those of you who were NOT on the old iCAP list
(pwg(_at_)catarina(_dot_)usc(_dot_)edu) please let me know if you have
NOT be receiving the conversation about iCAP, one below.
X-Authentication-Warning: catarina.usc.edu: majordom set sender to
owner-pwg(_at_)catarina(_dot_)usc(_dot_)edu using -f
Date: Tue, 12 Dec 2000 00:06:53 -0800 (PST)
From: Donald Gillies <gillies(_at_)netapp(_dot_)com>
To: cerpa(_at_)ISI(_dot_)EDU, jelson(_at_)ISI(_dot_)EDU
Subject: the meeting where we decided about not including POST in respmod
Cc: gillies(_at_)netapp(_dot_)com, pwg(_at_)catarina(_dot_)usc(_dot_)edu
Sender: owner-pwg(_at_)catarina(_dot_)usc(_dot_)edu
i remember because it was the same meeting where mike condry started
to talk about where to go out to dinner.
there are something like 4 problems with this --
(a) you may have to store an unlimited amount of POST data on disk
to do this, which can be painful and inefficient.
(b) per roy fieldings complaint, icap was starting to diverge into
something that was no longer just sitting on the wire modifying
transactions, rather, it was starting to look at transaction histories
that could no longer be affected.
(c) we have absolutely NO application that is asking for this feature;
when in doubt, leave it out (ya know, end-to-end arguments in systems
design). the client can reimplement this feature by registering for
both reqmod and respmod transaction, and modifying requests to insert
a "correlating" transaction ID into the request, voila - it's part of
the end-to-end principal to leave it for the higher layer to
reimplement (it's not a performance or reliability optimization,
certainly).
- Don
Michael W. Condry
Director, Internet Strategy
2111 N.E. 25th Ave.
JF3-206
Hillsboro, OR 97124-5961
Phone: (503) 264-9019
FAX: (503) 264-3483
Email: condry(_at_)intel(_dot_)com