Re: An Open And Extensible Personalised Proxy Framework

Does any of this make any sense?  Well, yes and no.

The desire to combine adaptive smarts contributed by diverse authors is
very real.

Encapsulating each contribution as an HTML filter and then applying them
somehow via a pre-processor outside the browser runs into functional
limitations if each filter doesn't do a full compile on the document, and
composing filters from different authors runs into compatibility problems
if they are not carefully designed against a shared logical model of the
generic document.

A "more pain, more gain" alternative is to add adaptive smarts in the
middle end of a genuine compile process.  Let a shared first pass [the
browser?] build a DOM image of the received document, transform this data
structure to adaptive advantage, and then return it as a DOM image to the
output phase of the browser and possibly alternate rendering engines
outside the browser for delivery to I/O devices.

[In the WAI-PF working group, we have provisionally persuaded Dave Pawson
to think in these terms for Braille.]

There is a temptation in a filterlet to take short cuts, do simple
transforms that do not get to the true semantic structure of the document.
Defining the adaptive transforms in a way that they do not interfere with
one another takes some serious software engineering.  Domain abstraction is
one way to do this engineering.  The methods proper to each domain use
abstract references to methods in other domains so that any adaptive shift
in the other domain can take effect concurrently with the self-domain
method.  Sorry if this is babble.  I suspect that a working medium that
supports multiple heredity well may be needed if we want adequate mix and
match capability over our experimental techniques.  Java may not be OO enough.

In practical terms, if we write transforms against the DOM in Java, then
they can be applied using existing scaffolding in both client and server
contexts, at least for enough people so that we can do distributed user
testing.

The MAVIS people are writing their (e.g. math to Braille) transforms in
logic language.  They get to deal with math so the transforms that they do
exhibit a highly logical structure.  But (as an unreconstructed math fan) I
am suspicious that this approach would be beneficial for adaptive
transformers, too.

Al

At 05:15 PM 6/3/99 +0100, Wayne Myers-Education wrote:
>> 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
>forth.
>
>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'
>issue.
>
>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
>http://www.bbc.co.uk/education/
>0181-752-6116
>

Received on Friday, 4 June 1999 10:48:18 UTC