Re: Agent-mediated access (was Re: Criticism of Kidcode...)

On Jun 19,  8:46pm, Peter Deutsch wrote:

> As we define them, URAs are capable of searching,
> accessing and filtering available Internet resources
> without requiring the user to provide, or even be aware
> of, specific access mechanisms. We don't use proxies,
> since we think architecturally it makes more sense to move
> the agent manipulation onto the desktop, as this is the
> cheapest resource the user can access. Still, I think they
> can do what you want out of the box.

Requiring proxies is not a great idea, but being able to use
them is important, especially for the class of users most likely
to need ease-of-use; those on aol.com, compuserve.com, ...
Also, my take on Brian's message was that the proxy server was
at the firewall, so this does seem to make a lot of architectural
sense.


> Architecturally what distinguishes URAs from other agent
> proposals, such as Knowbots or Hot Java, is that we focus
> on URAs as objects that exist and are managed in the
> client's local space.
...
> With this approach we do not require trusted access to
> outside servers to run (a la Knowbots), nor do we assume
> that we will be down-loading applets from non-trusted
> outside servers (a la Hot Java).

I agree that a lot of the management of agents should happen
locally. However, there is an important search component that
should happen remotely. Currently, the most sophisticated remote
query capabilites that are common on the web are PERL regexps.
We expect that to get better and better. Mark Madsen alluded to
this with his message about providing partial URCs as search templates,
augmented with methods that would be run remotely to do the query.

While HotJava, the browser, downloads applets and runs them locally,
note that it would be possible to invert this so that a server would run
Java bytecode programs your browser uploaded to it. This does not have
the mobility of TeleScript, but provides considerable capability for
special searches. It does require the server open itself up to incoming
code fragments, but it can do some checking to make sure that the
fragments don't do obviously nasty things.


> This doesn't mean all processing should be on the client
> machine, but we should look at approaches that move at
> least some of it onto the desktop since, as I said earlier,
> it's the cheapest net resource a user has access to.

I agree. Being able to specify remote computation does not mean
I want all computation to be done remotely. Just where the
dividing line should be drawn will depend on the capabilites of
the client and the characteristics of the network link. 


Regards,

-- 
Ron Daniel Jr.                email: rdaniel@acl.lanl.gov
Advanced Computing Lab        voice: (505) 665-0597
MS B-287  TA-3  Bldg. 2011      fax: (505) 665-4939
Los Alamos National Lab        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM,  87545    tautology: "Conformity is very popular"

Received on Tuesday, 20 June 1995 11:09:24 UTC