Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Monday 21 January 2002 11:09 pm, Miles Sabin wrote: > Not quite. Suppose the response endpoint is disconnected when the > responder attempts to call back. Yes, the responder can retry later, > or maybe consult some registry or other for an alternative target > URI. Right. Pretty trivial to do. > But look what we're doing here: we're layering another protocol on > top of HTTP, a protocol which doesn't match HTTPs semantics very > well. I'm not saying it _can't_ be done with HTTP, just that there > are better ways of going about it. FWIW. I agree with you. I was just pointing out the way this can be achieved. As I said, I proposed something like this as an alternative to file upload back in '95 or so. After thinking about it more, I believe the simplicity hides hard questions (and in actual fact, I learned my lesson even earlier, but failed to heed it). Web services suffer from a similar set of issues (discoverability, security, etc.) that are completely orthogonal to issues of performance (asychronicity etc.) and which were never adequately answered for CORBA et al. either. As everyone knows, sooner or later, the client *must* become smarter. REST etc. are only (maybe) one part of the solution, but I feel we need something *designed* to support it, rather than *hacked* to support it. Sadly, designs are never correct, and impossible to do well with large groups... so in all probability, the hacks will win.
|
