|laziness, impatience, and hubris|
Re: RFC on a system for automated agentsby AgentM (Curate)
|on Apr 17, 2001 at 08:04 UTC ( #73045=note: print w/replies, xml )||Need Help??|
Being an automated agent, I feel qualified to answer your question.
This project seems to have alot of similarity to CGI::Application in which "states" are assigned to various user-interactions which may be intertwined. But it seems that you want your "agentm" to also be able to have drivers for other display methods. Correct me if I'm wrong, but perhaps you're looking for the database entity "view" in which an SQL query is stored for later use and data sets are constructed- perhaps for different users or for different requests. Perhaps you're looking for some answers where to make divisions in your implementation so that your model is extensible later? I see three basic steps:
This may seem a little vague or cliche/useless, so each section deserves some discussion. 1. This info retrieval, depending on the complexity of the app, may involved stored queries- in fact, I recommend it. The SQL queries may even be built from the user input as you request on the fly. This is simple to implement and the best way to lead into 2. which may include templates, sorting, and your heuristics. Such an agent would, of course, be a module and be "hot-swappable", i.e. this running instance needs Agent #X while the next one requires #Y. Essentially, you would need an Über-Agent watching the under-agents perform their regular duties. I would make this Über-Agent an IPC-reachable daemon, so that it has the potential to take have a command-line client and other programs may check on various stati, or request permission for a "session". Obviously, signals won't cut it. You say that processing may take place later- that's fine. I probably wouldn'y push it as a cron job since that incurs an amount of overhead and is generally unnecessary for one time tasks. Instead, allow your Über-Agent to handle it. 3. Obviously, the agent-filtered data will need to be fed through various lines, whether it be CGI or Curses. For this task, I might recommend XML, so that your end graphical clients might easily pick up on the what's to be displayed. In fact, this would allow for later innovation in the area of remote GUI clients.
You'll probably come to the conclusion that the agent's design will eventually be built around the incoming data instead of much else- at least that's how it sounds to me. I see incoming data being individually processed by a human- correct me if I'm wrong. Along those lines, it might be worth reconsidering whether you actually want a web interface since it is grossly limited in its ability to interact with the user. Eventually, it would become the "dumbed-down" interface. I urge you not to limit your GUI drivers to this limitation since you might eventually find that the command-line interface or even the X/Gtk/Tk/whatever interface may be easier to use (heck, I'll say it, how 'bout a Java-applet interface? Still a "web page", right?)
Now that I think of it, your SQL-level queries could actually be a subset of the agent, but this MAY limit you later when it comes to more robust agents that do something other than crunch numbers. Either way, DBI shortcuts are the way to go. But like I said, keep an extra layer of abstraction between the GUI and agent.
Additional features? Well, I already have a genie agent crunching my data before I view it, could there be actual user-level controls for this agent? Perhaps this is unrealistic, but if the agent is designed as a base module built under an easy to understand Perl interface, certainly it's not unimaginable that the user could build his own agents including heuristics or whatever else is used to build the end-user-result. And if you get the GUI-independent display off the ground, that could be a hit module in itself. This actually sounds alot like what I'm working on now- only more impressive. Good luck!
Update: Perhaps DBIx::Renderer could find a use in your program?
AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
In Section Seekers of Perl Wisdom