> Couldn't we have the defaultAction of the new HTTP exceptions return 
> the same error Strings that they do now? This will result in no 
> client code needing to change, but allowing future code to trap the 
> exceptions.

We could, but is it worth it?  This interface really sucks, and isn't it
the Squeak culture to favor correctness over legacy support?   Maybe we
should let Michael design it from scratch as he sees fit.  I doubt it
will involve returning a string to indicate an error.  :)


Even if we decide that legacy support is important (I don't think it
is), then we still have the option of *abandoning* the legacy interface
while creating the new one, and then retrofitting it later.  Designing
this interface is hard enough even from scratch, and the existing
interface is skimpy enough to be retrofitted in 5-10 minutes onto any
reasonable HTTP library.



-Lex