> While I understand many of Roy's objections I do not agree that many
> of them need to be a problem.
I had a draft message which basically said the same as Derek's :-)
The hazard of notification storms is real, as is the notification of
temporary problems, but that could be configurable.
Derek raised the question if notification response should be
implemented in the server. The same question goes for the notification
sending. I see a few possibilities:
a) Built notification sending into the server. This means everyone
gets it automatically with their server, but it may be a bit tricky
to maintain state (when you last sent what notification to who).
b) Run a sending script over the logs. Means we could experiment/
implement it RSN, puts a human in control, let's us add a
'use-this-link-instead' database, and means you're not
likely to get storms as you can easily maintain state.
c) Receive notifications as an HTTP method in the server. Means
everyone gets it automatically, but it may not be too configurable,
and requires an HTTP change.
d) Standardise a URL to post a standard form to (/cgi-bin/broken).
This can then be handled by a CGI script. Means we could
experiment/implement now, but requires some effort to set up
(unless servers install it by default).
e) Don't standardise the receiving at all, but use heuristics like
Michael Chang's scripts. Means we don't have to standardise
anything, but continue with responding to email.
While I favour the flexible ways (b & d), I think it's going to be
even more dificult to standardise operational behaviour than protocol
(and we now how much fun that is :).
Of course, this HTTP solution doesn't work for non-http protocols,
which can also have broken links.
> I realise that this approach is only a partial solution to the
> problem, but I do not see any total solutions on the horizon so I
> think a partial one is better than none.
Hmmm... I agree with Dan and others that we should see if we can steal
ideas from other systems/mechanisms first, but I'm not sure that we can,
or even want to, drastically change the way the web works now.
-- Martijn
__________
Internet: m.koster@nexor.co.uk
X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
X-500: c=GB@o=NEXOR Ltd@cn=Martijn Koster
WWW: http://web.nexor.co.uk/mak/mak.html