From: "Ronald E. Daniel" <firstname.lastname@example.org> Message-Id: <9506200909.ZM2297@idaknow.acl.lanl.gov> Date: Tue, 20 Jun 1995 09:09:12 -0600 In-Reply-To: Peter Deutsch <email@example.com> To: Peter Deutsch <firstname.lastname@example.org> Subject: Re: Agent-mediated access (was Re: Criticism of Kidcode...) Cc: email@example.com 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: firstname.lastname@example.org 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"