I was thinking today about an "agents service." The idea is that you
set up "agents" -- little scripts that accomplish tasks for you like
sending out an announcement e-mail constructed from a form (I'm not a
spammer -- I manage a seminar talk series and send out weekly
announcements), searching the 'net and compiling an RSS feed of the
day's goodies, or the like. You set up each agent to execute
periodically, much like a *nix cron job.
The architecture would be built on a multithreaded CL. It comes in
parts:
* Each agent is just a collection of (thread-safe) functions. A
single function, RUN, is sufficient; there are other defaults that can
be overridden.
* Agent service: it's like *nix's cron. It runs in one thread, and
sleeps until it's time to wake up some agent, which it does by calling
the agent's RUN function. We don't allow an agent's RUN function to
be invoked if a previous invocation is still running -- that results
in an error message sent to the user (say, via e-mail). Each
invocation of an agent's RUN happens in its own thread. Agents can
only run periodically.
* Resource interface: we try to limit agents' use of certain limited
resources, like space on disk. I'm not sure how much of this should
be up to the OS. Motivating example: suppose an agent is given a
task to append to some file every day with a set of search results.
If the file gets too big, bad things will happen. The resource
management interface signals the user (say, via e-mail) if a
particular agent is being bad.
Users talk to the agent service or to agents via a Lisp listener.
(Some thread safety issues to think about there. I would only allow
local or ssh-tunneled access, for security reasons.)
Basic tools for agents would be Web 2.0 - type technologies for
interacting with things like Google Mail (Emacs has a nice interface,
for example -- probably easily adapted to CL) or Yahoo Pipes. User
passwords would be mediated by a keychain (to avoid storing plaintext
passwords).
My questions for y'all are:
1. Has this been done before? Has it been done for CL?
2. Is it better just to leverage existing technology (like cron) and
spawn a Lisp process for each agent, or opt for an all-CL
implementation?
3. What other clever applications can you think of? I've mentioned
managing an e-mail list based on form letters, and periodic web
searches collecting into a feed. Pretty much anything with a Web API
is free game. Agents need not be limited to web things though -- this
is pretty much just an enhanced cron.
mfh
Hi Mark!
Don't get me wrong, but when you just want to have little scripts that run as
cron jobs -- as you are saying --, why burden yourself with the conceptual
overhead of agents?
As far as I know, there are two kind of agents: 1) those who migrate to
different platforms and use the facilities at their respective host and 2) those
who contain substantial amounts of knowledge about certain subparts of the
domain of application and jointly contribute to problem solutions.
Neither of these seem to be quite appropriate to the tasks you mention.
Maybe you could elaborate further on the reason why you want to use agents;
sounds like you an example for teaching a course or something similar.
Best regards!
-- Stefan Mandl
On Apr 25, 4:53 pm, Stefan Mandl <············@informatik.uni-
erlangen.de> wrote:
> Don't get me wrong, but when you just want to have little scripts that run as
> cron jobs -- as you are saying --, why burden yourself with the conceptual
> overhead of agents?
Maybe "agent" is too fancy of a word? They are basically just
independent cron scripts, though I'd like a smarter agent management
system that mediates communication from me to the agents.
> As far as I know, there are two kind of agents: 1) those who migrate to
> different platforms and use the facilities at their respective host and 2) those
> who contain substantial amounts of knowledge about certain subparts of the
> domain of application and jointly contribute to problem solutions.
> Neither of these seem to be quite appropriate to the tasks you mention.
That right -- my "agents" don't have to be that smart (though they
could be as smart as you like).
The main point of this project would be to make one's life easier :)
The agents would do small tasks like manage mass mailings, check bank
accounts, periodically search Usenet for keywords, and the like. They
would report to the user via e-mail or SMS messages.
The main point of using CL would be to leverage macros to define an
"embedded language" for agents, to make creating and modifying agents
easy. The agents and agents manager would all run on a single trusted
internet-connected machine. Ideally there would be security measures
in place that would (a.) notify the user of any changes to the system,
and (b.) shut down the system in an emergency.
I'm not actually teaching a course (though this would be a fun
semester project for a software engineering course :-D ) -- the point
here is only to make my life easier. I realized (a.) that I was
wasting time and worry on tasks that are quite scriptable, and (b.)
that if I were to automate those tasks, it would be desirable to have
a single protocol and to manage all the tasks in one place that is
under my direct control (e.g. I could run security measures on the
system and disconnect it if I had reason to suspect it had been
cracked).
So -- hope it's not a disappointment that I'm not doing fancy AI ;-P
and many thanks to all for the suggestions!
mfh
Hi Mark,
Don't be discouraged! My response really -- and now I can tell you -- was a kind
of challenge in order to understand why you came up with the idea of using
agents for your project ;)
And it seems to me, here we have it:
> The main point of using CL would be to leverage macros to define an
> "embedded language" for agents, to make creating and modifying agents
> easy. T
As you'd like to define a new programming language, it now seems to me perfectly
adequate to discuss the use of agents as a metaphor for that language.
The point is that 1) now agents serve as a way for the *user* to describe
behavior and 2) agents as a programming language construct have to have exactly
specified semantics!
This is of course a totally different story than to use agents as an
implementation technology with a little hope for some magic happening
somewhere ;)
I'd like to encourage you to reveal to us some ideas about the features and
possible expressions of this "soon-to-be-created" new CL based agent programming
language.
Best regards,
Stefan Mandl
On Apr 27, 3:46 pm, Stefan Mandl <············@informatik.uni-
erlangen.de> wrote:
> I'd like to encourage you to reveal to us some ideas about the features and
> possible expressions of this "soon-to-be-created" new CL based agent programming
> language.
Um, all I really want is a fancy cron... *sheepishly backs away*
Seriously, my "agents" would be just cron jobs with some AJAX or the
like thrown in. There might be some macrology like DEFAGENT to make
defining agents quick and easy. No special programming language or
anything.
mfh
On May 1, 1:54 pm, ·············@gmail.com" <············@gmail.com>
wrote:
> On Apr 27, 3:46 pm, Stefan Mandl <············@informatik.uni-
>
> erlangen.de> wrote:
> > I'd like to encourage you to reveal to us some ideas about the features and
> > possible expressions of this "soon-to-be-created" new CL based agent programming
> > language.
>
> Um, all I really want is a fancy cron... *sheepishly backs away*
>
> Seriously, my "agents" would be just cron jobs with some AJAX or the
> like thrown in. There might be some macrology like DEFAGENT to make
> defining agents quick and easy. No special programming language or
> anything.
Yes, well, that's the spirit! Just define it with MACROS (yeah I luv
macros). After all, you already have THE special programming
language: LISP.
...come to think of it, what is the AJAX in there for? Are you using
JavaScript with XMLHttpRequest to setup the cron job? Shouldn't that
have some sort of separation of responsibilities, i.e. server code
calls cron set code?
On Apr 25, 5:57 pm, ·············@gmail.com" <············@gmail.com>
wrote:
> 3. What other clever applications can you think of?
I was actually planning on a distributed solution similar to this to
solve problems that require a lot of processing. Something like
····@Home (but I have no grand scheme like this). The nice thing is if
done right your can add as many "agents" as you want; these would just
grab some independent unit of work, do the work, and then pass the
results back.
Before I begin designing anything though I was going to refresh myself
on related patterns to see if I can follow a design that's already
solved. In this case I'm sure there is existing work on the problem.
> announcements), searching the 'net and compiling an RSS feed of the
> day's goodies, or the like. You set up each agent to execute
Here's one implementation of that idea that my company produced:
http://www.seeksift.com/
The SeekSift back-end (feed aggregator and query parser) is in CL, and
the front-end is chock full of AJAXy goodness.
It's been an interesting experimental project for us, but I'm not sure
whether or not there's a sustainable business in it.
·············@gmail.com" <············@gmail.com> writes:
> I was thinking today about an "agents service." The idea is that you
> set up "agents" -- little scripts that accomplish tasks for you like
> sending out an announcement e-mail constructed from a form (I'm not a
> spammer -- I manage a seminar talk series and send out weekly
> announcements), searching the 'net and compiling an RSS feed of the
> day's goodies, or the like. You set up each agent to execute
> periodically, much like a *nix cron job.
>
> The architecture would be built on a multithreaded CL. It comes in
> parts:
>
> * Each agent is just a collection of (thread-safe) functions. A
> single function, RUN, is sufficient; there are other defaults that can
> be overridden.
>
> * Agent service: it's like *nix's cron. It runs in one thread, and
> sleeps until it's time to wake up some agent, which it does by calling
> the agent's RUN function. We don't allow an agent's RUN function to
> be invoked if a previous invocation is still running -- that results
> in an error message sent to the user (say, via e-mail). Each
> invocation of an agent's RUN happens in its own thread. Agents can
> only run periodically.
>
> * Resource interface: we try to limit agents' use of certain limited
> resources, like space on disk. I'm not sure how much of this should
> be up to the OS. Motivating example: suppose an agent is given a
> task to append to some file every day with a set of search results.
> If the file gets too big, bad things will happen. The resource
> management interface signals the user (say, via e-mail) if a
> particular agent is being bad.
>
> Users talk to the agent service or to agents via a Lisp listener.
> (Some thread safety issues to think about there. I would only allow
> local or ssh-tunneled access, for security reasons.)
>
> Basic tools for agents would be Web 2.0 - type technologies for
> interacting with things like Google Mail (Emacs has a nice interface,
> for example -- probably easily adapted to CL) or Yahoo Pipes. User
> passwords would be mediated by a keychain (to avoid storing plaintext
> passwords).
>
> My questions for y'all are:
>
> 1. Has this been done before? Has it been done for CL?
Yes, pretty much done. Don't know about CL implementations. However, to a large
extent, everything you have mentioned has been done under various terms before.
The term 'agent' is possibly 'overstating' for what you propose. I was doing
research on what was called "autonomous mobile agents' back in 95. While there
isn't any (or at least wasn't any) clear definition of agent, typically, they
had certain characteristics. One main one was that they exhibited some level of
AI type behavior (especially relevant for autonomous agents).
Much of the work I did was based on Sowa's Conceptual Graphs, KQML (Knowledge
Query and Manipulation Language) and KIF (Knowledge Interchange Format). The
agents were mobile in the sense that they could package up their state and move
it to another server, where a loader would take that state information and
create a 'clone' agent that would continue processing on that host. There were
many helper agents that performed things like gatekeeper, message broker,
librarian (provided modules/routines to achieve certain tasks) etc. One
application was for searching of large data sets from multiple hosts. You wold
start an agent, give it some goal to achieve and then let it loose on the net.
It would use information/knowledge from various places to work out which hosts
to visit, process your query on the data available on that host and possibly
plan other actions for that and other hosts. The agent would move around
collecting information and then eventually return to you and report what it was
able to find.
Part of the idea was to change searching approaches from one in which you
tended to retrieve large data sets and then process them to a model in which
the maximum possible processing was done on the remote host, ideally returning
a much smaller data set that may be further analysed locally. (remembering that
net speeds were considerably slower in 95, especially if you were connected via
modem and that security concerns were less).
Most of the code was written in Tcl/Tk, prolog and C. A lot of work was coming
out of England at this time (Particularly from Nick Jennings and Mike
Wooldridge). DARPA was doing a fair amount of research on KQML/KIF and there
were some agent systems coming out of Stanford (I think - its been a while).
> 2. Is it better just to leverage existing technology (like cron) and
> spawn a Lisp process for each agent, or opt for an all-CL
> implementation?
At an abstract level, it all seems quite straight-forward. However, once you
start implementing, you realise that you pretty much need to write almost
everything (at least that use to be the case). Progress can be terribly slow if
you want a totally unified functional system in any one language. My avice
would be to leverage of any existing techniques/technology as much as possible.
One of the reasons I used Tcl was because it provided a convenient way to
'glue' different existing things together.
> 3. What other clever applications can you think of? I've mentioned
> managing an e-mail list based on form letters, and periodic web
> searches collecting into a feed. Pretty much anything with a Web API
> is free game. Agents need not be limited to web things though -- this
> is pretty much just an enhanced cron.
>
Well, there has been a fair amount of work in this area dealing with data
mining, stock quotes, data transalation between different systems to provide
'meta' level searching, analysis of legal documents/rulings, user interfaces
etc.
To be honest, I sort of lost interest/confidence in all the 'agent' related
stuff because too much of it was just existing technology being re-badged with
a cooler name. Many of the techniques were just re-discovered statistical
methods from the 60s, many of the ideas didn't address world realities, such as
security and much of it just represented more grand promises based on old ideas
that still had not solved fundamental problems that were first encountered in
the 50s and 60s. To some extent, the whole agent thing is not very different to
the traditional Unix philosophy of lots of small utilities that do one thing
well and you obtain more complex action/behavior by glueing them together
(compared to the big application approach).
Back in 95, I didn't know CL. However, I think it would be an ideal language to
use as a lot of agent development is about explorative development of little
bits of functionality that is then combined to give more complex behavior. If
you are specifically interested in web based stuff, I'd also recommend looking
at some of the 'semantic web' research. to what extent this stuff will be
realised is debatable, but I think the underlying concepts and goals are
interesting. In particular, you may want to look at DAML (The DARPA Agent
Markup Language).
Tim
--
tcross (at) rapttech dot com dot au
On 4985 September 1993, Tim X. wrote:
> The term 'agent' is possibly 'overstating' for what you propose. I
> was doing research on what was called "autonomous mobile agents'
> back in 95. While there isn't any (or at least wasn't any) clear
> definition of agent, typically, they had certain
> characteristics. One main one was that they exhibited some level of
> AI type behavior (especially relevant for autonomous agents).
[...]
> Much of the work I did was based on Sowa's Conceptual Graphs, KQML
> (Knowledge Query and Manipulation Language) and KIF (Knowledge
> Interchange Format). [...]
> Most of the code was written in Tcl/Tk, prolog and C. [...]
Just for the record: It was possible to do KQML in Lisp. A short
google query turned up http://www.cs.umbc.edu/kqml/software/, which
mentions some APIs in Lisp. I can't remember which we used, but it was
running on CMUCL (17 something, IIRC).
Holger
--
--- http://hillview.bugwriter.net/ ---
"Eher spende ich das Geld den Zeugen Jehovas."
"Kontonummer der Zeugen Jonas' auf Anfrage."
-- Robin Socha und Jonas Luster in dcoul.misc
On 25 Apr 2007 14:57:28 -0700, <············@gmail.com> wrote:
> I was thinking today about an "agents service." The idea is that you
> set up "agents" -- little scripts that accomplish tasks for you like
> sending out an announcement e-mail constructed from a form (I'm not a
> spammer -- I manage a seminar talk series and send out weekly
> announcements), searching the 'net and compiling an RSS feed of the
> day's goodies, or the like. You set up each agent to execute
> periodically, much like a *nix cron job.
>
> My questions for y'all are:
>
> 1. Has this been done before? Has it been done for CL?
I've been running those for awhile, but I don't need your fancy
clutter. cron handles this fine, running compiled lisp, easy with
cmucl and linux. The agent tasks you cite don't need the system you
suggest.
--
There are no average Common Lisp programmers
Reply-To: email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
This would make a useful and easy extention to KnowOS technology, and
I invite you to explore doing it in that paradigm. By using KnowOS
technology you wouldn't have to have your own server running all the
time. KnowOS already has a runjob command for batch tasks, and it
would be a very simple extension (I think) to add something like you
describe. (Just add some :repeat and/or :interval keywords.) Moreover,
KnowOS would give you complete through-the-web lisp-all-the-way-
down(and up!) control of your script farm (or, if you prefer: your
agent community :-) Indeed, this would be a pretty interesting
application for KnowOS technology; someone could make a little cottage
industry of running a little script farm KnowOS server.