W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > June 1999

An Open And Extensible Personalised Proxy Framework

From: Wayne Myers-Education <wayne.myers@bbc.co.uk>
Date: Thu, 3 Jun 1999 17:15:50 +0100
Message-Id: <41ED4776F432D211ACBD0000F8EF7D7A01287C55@w12wcedxu01.wc.bbc.co.uk>
To: WAI ER IG List <w3c-wai-er-ig@w3.org>
> There is room for a good open source project that
> incorporates betsy and friends into an open and extensible
> "personalized proxy" framework.

Yes yes yes yes yes yes yes.

I've been fiddling with ways of making Betsie work as a client-side solution
but have not managed to come up with anything even remotely satisfactory
yet. Whether or not the WAI take it on, I'm certainly extremely keen to look
at open, extensible solutions of this sort, and I'd love to know more about
Raman's personal perl proxy too.

In terms of client-side proxy filtering, I've been looking at the following
five-piece plan:

1 - A (accessible) user interface component handling issues like user
settings and preferences, turning the filter on and off, etc.
2 - A kind of mini-server component, being the proxy itself into which
filters like Betsie (or whatever) 'plug in', in addition to having potential
support for languages other than Perl if people insist on writing filters in
them (which they inevitably will).
3 - Betsie and/or other filters.
4 - Perl and/or the other scripting languages.
5 - An intelligent installation script that 'knows' as much as possible
about as many browsers as possible and makes it as easy as possible for
users to get everything set up, including the relevant proxy settings and so

The filters themselves are not a problem, or rather, are an ongoing problem
around which this is merely a utilitarian wrapper. It strikes me that Perl
is the ideal default scripting language for all of this, but then of course
I think that; meanwhile, it would be highly foolish not to include support
for arbitrary additional scripting languages.

In terms of the mini-server proxy component itself, I suspect that Raman is
several light years ahead of me - I've been working on one in Perl myself
but it doesn't work (yet) and I'd be delighted to abandon it in favour of
something that did. As for the architecture of the proxy, I simply don't
have the knowledge to say whether or not it should be a complete HTTP 1.1
implementation (in which case the 'mini' aspect of things seems a misnomer),
whether it would be ok to go for an absolutely minimal subset thereof, or
something somewhere in between; this is one of the main things hampering me
in finishing my own proxy bit, quite apart from the 'doesn't work yet'

Once those things are all in place, though, the UI and the installation
script(s) ought to virtually write themselves, although I suspect that some
language other than Perl might be required for the latter.

Does any of this make sense?

Cheers etc.,

Wayne Myers
Interactive Software Engineer
BBC Digital Media
Received on Thursday, 3 June 1999 12:16:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:28 UTC