The rewritten anonymity filter works significantly differently to the
old one, both internally and interface-wise. The old filter would check
the page, provide a list of violations, and then the user could click to
go to the page anyway, or to see the source. The new filter rewrites the
page, and never consults the user. Arguably the new way is safer and
more convenient for the user, normally, but not so great for the
author... there is now a choice of directions for the filter.
Option 0)
Don't change anything. Leave it exactly as it is now. The whole
page is processed in advance, but almost all errors are
transparently removed by default rather than causing a filter
exception. We do not buffer the different filter errors, so even
if I provide a config option to disable deleteWierdStuff (which
I haven't yet), and deleteErrors, the first error would be the
only one shown. This leads into Option 1).
Option 1)
Rewrite the filter to behave like the old filter - process the
whole page in advance, and when we have a problem, provide a
list to the user, giving options to serve the original page, to
view the source (i.e. display the page ?mime=text/plain), or to
display the page minus all questionable tags.
Option 2)
Rewrite users of the filter to take maximum advantage of the new
architecture by filtering the data as it is streamed in. Would
improve performance loading HTML pages, and make it seem a bit
less nonresponsive from the new user's point of view. However,
it would be very, very difficult, to send a specific error
message to the user - we would have to rewrite the HTML
(certainly possible, but the message could end up anywhere, in
any font, even invisible... various other options involving
javascript, <link> and RDF are all difficult for compatibility
reasons). It would also make it very easy to filter splitfiles,
a nice side-effect, and reduce or eliminate the need for fproxy
(but not splitfile) temp files.
Option 3)
Both of the above, switchable in a config option. More work...
it would be easier to pick one option and go with that.
What I want to know is is there any good reason to support option 1/3?
My preference would be 0 or 2. Comments?
--
Matthew Toseland
toad at amphibian.dyndns.org/amphibian at users.sourceforge.net
Freenet/Coldstore open source hacker.
Contracted full time by Freenet Project Inc.
http://freenetproject.org/
ICTHUS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20030107/b64e344d/attachment.pgp>
