On 3/7/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Mar 2007, at 18:59, demerphq wrote:
> Neither to me to be a very convincing reason to redesign something as
> well thought out as the HTTP response code schema. With it you have a
> well documented, well designed language agnostic response structure.
> It seems to me youd have to work hard to come up with something
> better.
We already have an interface that's even closer to home: emit an
error message and return non-zero status.
As I say I'm not thoroughly opposed to using HTTP like responses;
just not convinced that even that level of complexity is necessary.
I guess it comes down to whether you can anticipate the possibility
that you will need new codes, and having a framework to put them into.
The nice thing about the HTTP scheme is it gives you a way to add new
codes that can be interpreted more or less correctly by something that
wasnt designed with those codes in mind. (For instance while a
particular client might not know what 569 is exactly, they should know
its a server error.)
If you do go so far as to design a new protocol for this please take a
minute to read the RFC's for the HTTP response code schema and the
SMTP response schemas. The SMTP schema goes a bit further than the
HTTP one, in that it also defines special meaning for the second digit
as well as for the first.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
