Menu
▾
▴
agentfactory-developer — This mailing list is intended to be used by Agent Factory developers
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(14) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(3) |
| 2016 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Rem C. <rem...@uc...> - 2005-04-29 12:55:06
|
For me, it is important that the following be included in the next release: * Remote command Service (would like to finish the message monitoring tool for this) * Platform Service security model + reimplemented AMS * more working examples * The refactored SuperDF code with the database connectivity as optional Robert Ross wrote: > Hey Rem et al, > I suggest that we should consider making a release soon. To that end, > we should probably make a list of features that we wish to have in and > stable. > > suggestions? > > rob -- ------------ Dr Rem Collier Room A1.02, Department of Computer Science, University College Dublin, Belfield, Dublin 4, IRELAND tel: +353 (0)1 716 2465 www: http://agentfactory.sourceforge.net |
|
From: Robert R. <ro...@in...> - 2005-04-28 16:12:17
|
Hey Rem et al,
I suggest that we should consider making a release soon. To that end, we=20
should probably make a list of features that we wish to have in and stabl=
e.
suggestions?
rob
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Robert J. Ross
--------------------------------------------------------------------
Mail FB3, Mathematik-Informatik
Universit=E4t Bremen
Postfach 330 440
28334 Bremen
Deutschland
Phone +49 421 218 7129
Fax +49 421 218 3054
Web http://www.informatik.uni-bremen.de/~robertr
Email ro...@in...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|
|
From: Robert R. <ro...@in...> - 2005-04-21 15:20:17
|
that sounds fair enough. Certainly the configuration of the platform=20
should be the done first. Also, it is, I suppose, logical that system=20
agents get created before application agents. One caveat however is that=20
if the application agents take a non-trivial approach to service=20
registration etc. then they would be able to register with system agents=20
even if those system agents were created after the application agents.=20
In any case, I still agree with the 'schedule' below.
rob
Rem Collier wrote:
> Hi guys,
>=20
> After a brief "off-line" chat with Donal about his SuperDF service, it=20
> has become apparent that we need to make sure that the initialization=20
> sequence on an agent platform is robust and well-defined. This mail is=
=20
> to get the discussion started, so here's my model...
>=20
> 1. Configuration of Platform
> 2. Setting up of System Agents
> 3. Creation of Application Agents
>=20
> How does this sound?
>=20
> rem
>=20
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Robert J. Ross
--------------------------------------------------------------------
Mail FB3, Mathematik-Informatik
Universit=E4t Bremen
Postfach 330 440
28334 Bremen
Deutschland
Phone +49 421 218 7129
Fax +49 421 218 3054
Web http://www.informatik.uni-bremen.de/~robertr
Email ro...@in...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|
|
From: Rem C. <rem...@uc...> - 2005-04-21 15:04:14
|
Hi guys, After a brief "off-line" chat with Donal about his SuperDF service, it has become apparent that we need to make sure that the initialization sequence on an agent platform is robust and well-defined. This mail is to get the discussion started, so here's my model... 1. Configuration of Platform 2. Setting up of System Agents 3. Creation of Application Agents How does this sound? rem -- ------------ Dr Rem Collier Room A1.02, Department of Computer Science, University College Dublin, Belfield, Dublin 4, IRELAND tel: +353 (0)1 716 2465 www: http://agentfactory.sourceforge.net |
|
From: Rem C. <rem...@uc...> - 2005-04-20 11:43:21
|
Okay, Donal, I accept your point on the database querying versus message passing, however personally i think that this has a number of key drawbacks: 1. loss of robustness (as mentioned by Rob) 2. Security of data - what if we don't want an AMS to have access to ALL the data held by a SuperDF? i.e. we may, in the future, want to apply domain based security policies that constrain who an agent can contact etc. 3. It forces all developers to use a database - this would seem to be a sizable overhead, and would make installation somewhat more difficult - they not only may not use the service (as rob points out), they may not use agent factory either. This is a SERIOUS issue, given we are starting to get increased exposure! While I understand Robs "Against" point that developers may not use the SQL based Super DF, I would argue that developers will use it if there is an advantage to using it. I perceive that such an advantage could be gained through the development of tools to support domain-oriented security policies, visualisation tools, etc. Finally, I think that we should use the sourceforge mailing lists for these discussions as they allow us to share our ideas and thoughts with other developers who may find these topics of interest... As a result, I have also CC'd this email to the agentfactory-developers mailing list! Rem Robert Ross wrote: > Hey lads, > Thanks a million for the replies. I now have a much better > understanding of the issues. I'll just list out some of my thoughts, > but bare in mind my naivety when it comes to superDF issues. > > Points on superDF architecture: > > * While I completely take Donal's point about communication overhead > in passing SuperDF information between multiple SuperDFs, I have a > problem with using one, or a small number of, superDF databases. This > introduces a point of critical failure into the entire MAS -- surely > not a good thing for a distributed system. If for any reason that > database because inaccessible, then all multi-platform applications > dependent on that database are going to have issues. I'm not saying > that a single or small number of databases isn't a possibility, I'm > just saying that we have to consider this introduction of a point of > critical failure. > * A second point on the centralized database approach is that for > practical or security reasons, many developers may need to create > multi-platform applications which are not dependent on a centralized > superDF database. > > Points on superDF implementation: > Now, as to whether a hashtable implementation of the superDF backend > has to be introduced, well that is just an issue to pros and cons: > FOR: > * Agent Platform remains lightweight, with no additional constraints > for multi-platform implementations > Against: > * Multiple superDF backends have to be maintained. > * Newcomers would be unlikely to use SQL based superDF (or a > centralized superDF) > > > thats all for now, > > rob > > > > Donal O'Kane wrote: > >> Rob, >> >> 2 is easier to answer, this is my fault I was debugging agentfactory >> on an ipaq and must have forgotten to uncomment the startup lines for >> the system agents. Sorry. >> >> 1 is a bit harder. >> >> Pro for database: >> A single database gives all the superDF agents the ability to pool >> their naming knowledge and so they can easily query from the entire >> set of registered agents and can avoid costly messaging of all >> superDF's. >> >> Initially the plan was to have only 2 superDF's running, on servers >> here in the department, and all agent platforms would connect to them >> (unless they were quick tests and just wanted to create their own >> local superDF). >> >> But the number of superDF's is scalable, and the central database >> seems to be the best approach form a message cost point of view. >> >> Cons: >> Well .. you need to run a database, if any user want to run a superDF >> they need a database ... OR they need to have a url, username and >> password for an already existing agent factory database .... which is >> how it most likely would be., agentfactory.com could run an sql >> database and get new platform admins to register to get a database >> username and password .. >> >> pros for hashtables: >> No worries with databases >> >> Cons: >> Increased communication costs and query complexity. >> >> Notes about the hashtable approach: >> >> The lightweight hashtable approach means that upon receiving a new >> registration the superDF must either >> A: send this registration to all other superDF's (so that all >> superDF's contain a full list of all registered agents) >> >> or >> >> B: the superDF must check to all other superDF's to ensure that the >> newly registered agents name is unique >> >> Also their must be methods that will allow a superDF to poll all >> other superDFs to see does a queried agent name exist, which with a >> small number of superDF's is ok but if you want to scale up, this can >> become a huge overhead of communication. >> >> Is my opinion anyway ... Sorry about the horribly written mail, it >> was a bit of a brain dump, hope it makes sense. >> >> Donal >> >> Robert Ross wrote: >> >>> Hi Donal, >>> I cc'ed Rem on this, because it is more of a topic for group >>> discussion then the usual code/CVS things. >>> >>> Anyway, my first question is: >>> 1. Are SQL databases really a good idea for the SuperDF? >>> I admit that I know little about what range of information the >>> SuperDF does usually have to retrieve and store, but requiring any >>> 'connected' Agent Factory platform to run an SQL database sounds a >>> bit harsh to me. I understand that there might be an argument for >>> developing a fall-back to Hashtables when SQL is not available, but >>> this sort of approach means that the light weight hashtable approach >>> is not developed sufficiently. >>> >>> 2. Why were the >>> agentManagementSystem.resumeAgent(<agent>.getName()); lines >>> commented out of the AgentPlatform.createSystemAgents() method? Is >>> this part of some new AMS control model or something? Because, for >>> me it just meant that my system agents never started. >>> >>> rob >>> >>> Donal O'Kane wrote: >>> >>>> Hi, >>>> >>>> Sorry about the late reply, this is an error I have yet to fix (ie >>>> if you do not have an sql database running use hastables or an >>>> arraylist to store the data in. >>>> >>>> So to run a superDF currently you must configure an sql server .. >>>> the superdf will setup the correct table for you if it does not exist. >>>> >>>> (note because the superdfs all share the one database currently, >>>> you have to either drop or empty the table before you start the >>>> superdf (or else some agents will already be registered in the >>>> database) >>>> >>>> >>>> The line you need is : >>>> >>>> SERVICE common.sql_service.superDFDatabase >>>> com.agentfactory.plugins.services.database_service.SQLCommandService >>>> jdbc:mysql://localhost/agentfactory agentfactory agentfactory >>>> agentregistry >>>> >>>> where the parameters are: >>>> >>>> a) jdbc:mysql://localhost/agentfactory >>>> # The URL to the database (here agentfactory is the dtabase name on >>>> the server localhost >>>> >>>> b) agentfactory >>>> #The username for the database >>>> >>>> c) agentfactory >>>> #The password for the database >>>> >>>> d) agentregistry >>>> # An optional argument for the SuperDF, It tells the >>>> SQLCommandService to setup the agentregistry table. >>>> >>>> >>>> hope this helps >>>> >>>> Donal >>>> >>>> Robert Ross wrote: >>>> >>>>> hey, >>>>> thanks, it's compiling now. Now, as for running it, what line do I >>>>> need to add to the platform configuration file for the SQQL >>>>> service. I'm getting an error that the SuperDF failed to bind to >>>>> common.sql_service.superDFDatabase. >>>>> >>>>> I'm guessing that the line should be something like: >>>>> SERVICE >>>>> com.agentfactory.plugins.services.database_service.SQLCommandService >>>>> But, does it need parameters? >>>>> >>>>> cheers >>>>> >>>>> rob >>>>> >>>>> >>>>> Donal O'Kane wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I think i have fixed that now, really sorry about that I was >>>>>> heading to a wedding early on Friday and spent a frantic 20 mins >>>>>> here trying to get all of my new stuff committed. I hope it work >>>>>> now, I think it was just the one class, DomainDescription that >>>>>> was causing problems. >>>>>> >>>>>> Donal >>>>>> >>>>>> Robert Ross wrote: >>>>>> >>>>>>> Donal, >>>>>>> I noticed that you've checked in most of your stuff -- thanks. >>>>>>> But, are you finished? cause I still have two compilation bugs; >>>>>>> namely: >>>>>>> >>>>>>> The method containsPlatform(String) is undefined for the type >>>>>>> DomainDescription SuperDFModule.java >>>>>>> AgentFactory/src/0.2-branch/com/agentfactory/plugins/core/fipa/superdf/module >>>>>>> line 92 15 April 2005 13:29:27 >>>>>>> >>>>>>> >>>>>>> The method newPlatform() in the type DomainDescription is not >>>>>>> applicable for the arguments (String) SuperDFModule.java >>>>>>> AgentFactory/src/0.2-branch/com/agentfactory/plugins/core/fipa/superdf/module >>>>>>> line 111 15 April 2005 13:29:27 >>>>>>> >>>>>>> >>>>>>> Hope this helps >>>>>>> >>>>>>> rob >>>>>>> >>>>>>> Donal O'Kane wrote: >>>>>>> >>>>>>>> will do now >>>>>>>> >>>>>>>> sorry still getting to grips with cvs >>>>>>>> >>>>>>>> >>>>>>>> oh and I checked out the agent platform and hard coding of the >>>>>>>> database service ... I already had removed the coded for that >>>>>>>> .. just had not removed the initialisation of the object. >>>>>>>> >>>>>>>> >>>>>>>> Donal >>>>>>>> >>>>>>>> Robert Ross wrote: >>>>>>>> >>>>>>>>> Hey Donal, >>>>>>>>> Sorry to bug you again, but I been having some problems >>>>>>>>> merging my code back into the tree. Specifically, it seems >>>>>>>>> that the database_service plugin has not been added to CVS, >>>>>>>>> thus causing compiler errors for the SuperDFModule. >>>>>>>>> >>>>>>>>> Could you check to see if it seems to have been added to CVS >>>>>>>>> from your end? >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>> Donal O'Kane wrote: >>>>>>>>> >>>>>>>>>> Em .. my bad .. >>>>>>>>>> >>>>>>>>>> its currently hard coded so I could get it working fast ... >>>>>>>>>> >>>>>>>>>> A lazy way to do it i know, but i'm in the process of fixing it. >>>>>>>>>> >>>>>>>>>> Donal >>>>>>>>>> >>>>>>>>>> Robert Ross wrote: >>>>>>>>>> >>>>>>>>>>> Hey there lads, >>>>>>>>>>> Listen, I'm a little confused about this addition of an SQL >>>>>>>>>>> service to the Agent Factory platform. Or, more to the >>>>>>>>>>> point, I'm a bit concerned over how it was added to the >>>>>>>>>>> platform. >>>>>>>>>>> >>>>>>>>>>> I've no doubt that an SQL writing/querying service is very >>>>>>>>>>> continent for a number of agents, and no doubt a platform >>>>>>>>>>> service plugin is ideal for this. However, why has the >>>>>>>>>>> 'plugin' been hard-coded into the agent platform (c.f. >>>>>>>>>>> AgentPlatform.java)? >>>>>>>>>>> >>>>>>>>>>> The MTS and RCS are both hard-coded services, and I can >>>>>>>>>>> understand that since they are both provide 'core' >>>>>>>>>>> functionality. I'm not so convinced about SQL access; if we >>>>>>>>>>> just add services ad-hoc to the platform it's going to bloat >>>>>>>>>>> and become a pain in the ass to maintain. >>>>>>>>>>> >>>>>>>>>>> Anyway, thats my point of view, but naturally I could be >>>>>>>>>>> wrong. What do the two of you think? >>>>>>>>>>> >>>>>>>>>>> cheers >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- ------------ Dr Rem Collier Room A1.02, Department of Computer Science, University College Dublin, Belfield, Dublin 4, IRELAND tel: +353 (0)1 716 2465 www: http://agentfactory.sourceforge.net |
|
From: Rem C. <rem...@uc...> - 2005-04-12 12:39:48
|
Hi all, An initial version of some of the guides that will make up the Agent Factory User Manual are now available from: http://www.agentfactory.com/agentfactory/manual/index.htm. Any feedback on these guides will be greatly appreciated! Many thanks, Rem Collier ------------ Dr Rem Collier Room A1.02, Department of Computer Science, University College Dublin, Belfield, Dublin 4, IRELAND tel: +353 (0)1 716 2465 www: http://agentfactory.sourceforge.net |
|
From: Robert R. <ro...@in...> - 2004-09-30 16:30:41
|
Hi
Hot of the heels of rems implementation of the Remote Interface, I have=20
added an altered swing based interface to compliment the original.=20
Whereas the original was designed for a PDA, the new interface is more=20
desktop friendly. Having said that, the PDA friendly interface is still=20
there to be used.
FYI, I will be using this swing based interface as a prototype for an=20
SWT/Eclipse Development Environment.
cheers
rob
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Robert J. Ross
--------------------------------------------------------------------
Mail FB3, Mathematik-Informatik Deptartment of Mathematics
Universit=E4t Bremen & Computer Science
Postfach 330 440 University of Bremen
28334 Bremen P.O. Box 330 440
Deutschland 28334 Bremen
Germany
Phone +49 421 218 7129
Fax +49 421 218-3054
Web http://www.informatik.uni-bremen.de/~robertr
Email ro...@in...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|
|
From: rem c. <rem...@uc...> - 2004-09-11 05:43:14
|
hey rob - the list now seems to be working - but there is a BIG delay=
=20
in the delivery of messages...
Robert Ross wrote:
>Hi Rem,
>I've cc-ed the developer list in case it starts coming through.
>
>First, let me see if I understand the intended difference between AP=
S=20
>and RCS? You see the APS as something passive in nature, where a scr=
ipt=20
>is loaded, listed commands are executed, and results are channeled i=
nto=20
>stdout. While, on the other hand, the RCS would be a less passive=
=20
>protocol intended for hooking up to a remote GUI.
>
>If I my interpretation is correct, then I see a point to the=20
difference,=20
>but it is clear that the APS would be a subset of RCS commands, and=
=20
>perhaps the implementation could reflect this.
yeah - i agree. the only problem is with the link is that the APS=
=20
should only employ the agent management subset of the RCS commands.
>Also, do you really feel that it is worthwhile to let the current GU=
I=20
>design die? While deployment to computationally limited devices, and=
=20
>eventual deployment to enterprise style servers might favor your=
=20
>approach -- an awful lot of development (both developer development =
and=20
>user development) will most likely take place with a platform runnin=
g=20
>locally.
good point - so, we can keep the local gui as a testing and debugging=
=20
environment - maybe we should create a "debugging mode" for agent=
=20
factory?
my plan for the RCS part of a bigger plan to move to the concept of a=
n=20
"agent cluster" - namely that a set of machines can have af installed=
=20
on them, be remotely managed (i.e. we can use linux run level 3 so we=
=20
don't get the hit from the use of the gui). users should then be abl=
e=20
to "inject" agents into the cluster (code etc is automatically=20
deployed) and a built in autonomic management system will ensure that=
=20
the set of agents running of the machine is optimally configured for=
=20
robustness and efficiency... finally, my expectation is that the=20
cluster will be able to manage multiple concurrent agent applications=
=20
and there will be a number of views of the cluster (e.g an applicatio=
n=20
view will show the current distribution of the agents)
>That said, then maybe we can agree that the run-time environment mig=
ht=20
>have an RCS GUI (bandwidth permitting), but that the IDE (once=20
>redeveloped) would not be based on this design.
>
>Better go... I've got a meeting to go to.
>
>cheers
>
>rob
>
>
>
>
>rem collier wrote:
>> hey rob!
>>=20
>> i've spent the last 8 hours trying to send the following message t=
o=20
the=20
>> developer's list, but it hasn't come through yet, so i'm sending i=
t=20
>> direct to you (i'll cc all future ones). the mail is basically ab=
out=20
>> the RCS service...
>>=20
>> were we go:
>>=20
>> Hi guys,
>>=20
>> As my first post, i want to have a quick discussion about the remo=
te=20
>> command service (RCS) for agent factory. this service should allo=
w=20
>> users to remotely administer agentfactory platforms.
>>=20
>> currently, af provides a facility to remotely execute commands fro=
m=20
the=20
>> APS scripting language. this facility is an option that can be us=
ed=20
>> INSTEAD of specifying a startup script. while this is useful, it =
is=20
>> not the same as the RCS. the RCS service should be able to run in=
=20
>> tandem with a startup script. in addition, there are a number of=
=20
>> operations that an RCS should support which should not be supporte=
d by=20
>> the startup script (e.g. generating user friendly lists of active=
=20
>> agents). my goal for the RCS is to be much more than this. it sh=
ould=20
>> also allow users to manage the platform services that are availabl=
e. =20
>> in particular, i would like to be able to remotely start a monitor=
ing=20
>> service that can be used to present debugging information to the u=
ser.=20
=20
>> i could then user the RCS to shutdown this service when it is no=
=20
longer=20
>> needed. by including this facility, i am extending the remit of t=
he=20
>> RCS beyond the context of the scripting language (IMO: the scripti=
ng=20
>> language should NOT support configuration of platform services - t=
his=20
>> is the job of the platform configuration files).
>>=20
>> anyway, this is my opinion based upon a quick review of the existi=
ng=20
>> infrastructure. if there are no real problems, i intend to contin=
ue=20
>> with my work on this service (which will itself be deployed as a=
=20
>> plugin) and will show you a reasonable first version of it in the =
near=20
>> future.
>>=20
>> rem
>>=20
>> ps here is a list of commands that i would expect the RCS to suppo=
rt:
>> connect XX
>> close
>> create agent
>> create service
>> terminate agent
>> terminate service
>> resume agent
>> suspend agent
>> show agents (nicely formated output)
>> show services (nicely formated output)
>> list agents ('|' and CR delimited output)
>> list services ('|' and CR delimited output)
>> shutdown
>> restart
>>=20
>>=20
>>=20
>> ----------------------------------------
>> Dr Rem Collier<BR>Lecturer<BR>Department
>> of Computer Science,<BR>University Coll
>> ege Dublin,<BR>IRELAND.<BR>www: http://w
>> ww.agentfactory.com<BR>tel: +353 1 716 2
>> 465
>>=20
>
>--=20
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>Robert Ross
>--------------------------------------------------------------------
>Mail FB3, Mathematik-Informatik Deptartment of Mathematics
> Universit=E4t Bremen & Computer Science
> Postfach 330 440 University of Bremen
> 28334 Bremen P.O. Box 330 440
> Deutschland 28334 Bremen
> Germany
>
>Phone +49 421 218 7129
>Fax +49 421 218-3054
>Web http://www.informatik.uni-bremen.de/~robertr
>Email ro...@in...
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>
>
----------------------------------------
Dr=A0Rem=A0Collier<BR>Lecturer<BR>Department
=A0of=A0Computer=A0Science,<BR>University=A0Coll
ege=A0Dublin,<BR>IRELAND.<BR>www:=A0http://w
ww.agentfactory.com<BR>tel:=A0+353=A01=A0716=A02
465
|
|
From: Robert R. <ro...@in...> - 2004-09-11 04:46:22
|
Hi Rem,
I've cc-ed the developer list in case it starts coming through.
First, let me see if I understand the intended difference between APS=20
and RCS? You see the APS as something passive in nature, where a script=20
is loaded, listed commands are executed, and results are channeled into=20
stdout. While, on the other hand, the RCS would be a less passive=20
protocol intended for hooking up to a remote GUI.
If I my interpretation is correct, then I see a point to the difference,=20
but it is clear that the APS would be a subset of RCS commands, and=20
perhaps the implementation could reflect this.
Also, do you really feel that it is worthwhile to let the current GUI=20
design die? While deployment to computationally limited devices, and=20
eventual deployment to enterprise style servers might favor your=20
approach -- an awful lot of development (both developer development and=20
user development) will most likely take place with a platform running=20
locally.
That said, then maybe we can agree that the run-time environment might=20
have an RCS GUI (bandwidth permitting), but that the IDE (once=20
redeveloped) would not be based on this design.
Better go... I've got a meeting to go to.
cheers
rob
rem collier wrote:
> hey rob!
>=20
> i've spent the last 8 hours trying to send the following message to the=
=20
> developer's list, but it hasn't come through yet, so i'm sending it=20
> direct to you (i'll cc all future ones). the mail is basically about=20
> the RCS service...
>=20
> were we go:
>=20
> Hi guys,
>=20
> As my first post, i want to have a quick discussion about the remote=20
> command service (RCS) for agent factory. this service should allow=20
> users to remotely administer agentfactory platforms.
>=20
> currently, af provides a facility to remotely execute commands from the=
=20
> APS scripting language. this facility is an option that can be used=20
> INSTEAD of specifying a startup script. while this is useful, it is=20
> not the same as the RCS. the RCS service should be able to run in=20
> tandem with a startup script. in addition, there are a number of=20
> operations that an RCS should support which should not be supported by=20
> the startup script (e.g. generating user friendly lists of active=20
> agents). my goal for the RCS is to be much more than this. it should=20
> also allow users to manage the platform services that are available. =20
> in particular, i would like to be able to remotely start a monitoring=20
> service that can be used to present debugging information to the user. =
=20
> i could then user the RCS to shutdown this service when it is no longer=
=20
> needed. by including this facility, i am extending the remit of the=20
> RCS beyond the context of the scripting language (IMO: the scripting=20
> language should NOT support configuration of platform services - this=20
> is the job of the platform configuration files).
>=20
> anyway, this is my opinion based upon a quick review of the existing=20
> infrastructure. if there are no real problems, i intend to continue=20
> with my work on this service (which will itself be deployed as a=20
> plugin) and will show you a reasonable first version of it in the near=20
> future.
>=20
> rem
>=20
> ps here is a list of commands that i would expect the RCS to support:
> connect XX
> close
> create agent
> create service
> terminate agent
> terminate service
> resume agent
> suspend agent
> show agents (nicely formated output)
> show services (nicely formated output)
> list agents ('|' and CR delimited output)
> list services ('|' and CR delimited output)
> shutdown
> restart
>=20
>=20
>=20
> ----------------------------------------
> Dr Rem Collier<BR>Lecturer<BR>Department
> of Computer Science,<BR>University Coll
> ege Dublin,<BR>IRELAND.<BR>www: http://w
> ww.agentfactory.com<BR>tel: +353 1 716 2
> 465
>=20
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Robert Ross
--------------------------------------------------------------------
Mail FB3, Mathematik-Informatik Deptartment of Mathematics
Universit=E4t Bremen & Computer Science
Postfach 330 440 University of Bremen
28334 Bremen P.O. Box 330 440
Deutschland 28334 Bremen
Germany
Phone +49 421 218 7129
Fax +49 421 218-3054
Web http://www.informatik.uni-bremen.de/~robertr
Email ro...@in...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|
|
From: Rem C. <rem...@ho...> - 2004-09-11 00:06:24
|
Hi guys, As my first post, i want to have a quick discussion about the remote command service (RCS) for agent factory. this service should allow users to remotely administer agentfactory platforms. currently, af provides a facility to remotely execute commands from the APS scripting language. this facility is an option that can be used INSTEAD of specifying a startup script. while this is useful, it is not the same as the RCS. the RCS service should be able to run in tandem with a startup script. in addition, there are a number of operations that an RCS should support which should not be supported by the startup script (e.g. generating user friendly lists of active agents). my goal for the RCS is to be much more than this. it should also allow users to manage the platform services that are available. in particular, i would like to be able to remotely start a monitoring service that can be used to present debugging information to the user. i could then user the RCS to shutdown this service when it is no longer needed. by including this facility, i am extending the remit of the RCS beyond the context of the scripting language (IMO: the scripting language should NOT support configuration of platform services - this is the job of the platform configuration files). anyway, this is my opinion based upon a quick review of the existing infrastructure. if there are no real problems, i intend to continue with my work on this service (which will itself be deployed as a plugin) and will show you a reasonable first version of it in the near future. rem _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail |
|
From: Rem C. <rem...@ho...> - 2004-09-10 21:46:27
|
Hi guys,
As my first post, i want to have a quick discussion about the remote command
service (RCS) for agent factory. this service should allow users to
remotely administer agentfactory platforms.
currently, af provides a facility to remotely execute commands from the APS
scripting language. this facility is an option that can be used INSTEAD of
specifying a startup script. while this is useful, it is not the same as
the RCS. the RCS service should be able to run in tandem with a startup
script. in addition, there are a number of operations that an RCS should
support which should not be supported by the startup script (e.g. generating
user friendly lists of active agents). my goal for the RCS is to be much
more than this. it should also allow users to manage the platform services
that are available. in particular, i would like to be able to remotely
start a monitoring service that can be used to present debugging information
to the user. i could then user the RCS to shutdown this service when it is
no longer needed. by including this facility, i am extending the remit of
the RCS beyond the context of the scripting language (IMO: the scripting
language should NOT support configuration of platform services - this is the
job of the platform configuration files).
anyway, this is my opinion based upon a quick review of the existing
infrastructure. if there are no real problems, i intend to continue with my
work on this service (which will itself be deployed as a plugin) and will
show you a reasonable first version of it in the near future.
rem
ps here is a list of commands that i would expect the RCS to support:
connect XX
close
create agent
create service
terminate agent
terminate service
resume agent
suspend agent
show agents (nicely formated output)
show services (nicely formated output)
list agents ('|' and CR delimited output)
list services ('|' and CR delimited output)
shutdown
restart
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
|
|
From: Rem C. <rem...@ho...> - 2004-09-10 21:43:22
|
Hi guys, As my first post, i want to have a quick discussion about the remote command service (RCS) for agent factory. this service should allow users to remotely administer agentfactory platforms. currently, af provides a facility to remotely execute commands from the APS scripting language. this facility is an option that can be used INSTEAD of specifying a startup script. while this is useful, it is not the same as the RCS. the RCS service should be able to run in tandem with a startup script. in addition, there are a number of operations that an RCS should support which should not be supported by the startup script (e.g. generating user friendly lists of active agents). my goal for the RCS is to be much more than this. it should also allow users to manage the platform services that are available. in particular, i would like to be able to remotely start a monitoring service that can be used to present debugging information to the user. i could then user the RCS to shutdown this service when it is no longer needed. by including this facility, i am extending the remit of the RCS beyond the context of the scripting language (IMO: the scripting language should NOT support configuration of platform services - this is the job of the platform configuration files). anyway, this is my opinion based upon a quick review of the existing infrastructure. if there are no real problems, i intend to continue with my work on this service (which will itself be deployed as a plugin) and will show you a reasonable first version of it in the near future. rem _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 |
|
From: Rem C. <rem...@ho...> - 2004-09-10 21:32:58
|
At the 200th time of trying...
Hi guys,
As my first post, i want to have a quick discussion about the remote command
service (RCS) for agent factory. this service should allow users to
remotely administer agentfactory platforms.
currently, af provides a facility to remotely execute commands from the APS
scripting language. this facility is an option that can be used INSTEAD of
specifying a startup script. while this is useful, it is not the same as
the RCS. the RCS service should be able to run in tandem with a startup
script. in addition, there are a number of operations that an RCS should
support which should not be supported by the startup script (e.g. generating
user friendly lists of active agents). my goal for the RCS is to be much
more than this. it should also allow users to manage the platform services
that are available. in particular, i would like to be able to remotely
start a monitoring service that can be used to present debugging information
to the user. i could then user the RCS to shutdown this service when it is
no longer needed. by including this facility, i am extending the remit of
the RCS beyond the context of the scripting language (IMO: the scripting
language should NOT support configuration of platform services - this is the
job of the platform configuration files).
anyway, this is my opinion based upon a quick review of the existing
infrastructure. if there are no real problems, i intend to continue with my
work on this service (which will itself be deployed as a plugin) and will
show you a reasonable first version of it in the near future.
rem
PS here is a more detailed breakdown of the commands that i think the
service should support:
* create agent
* create service
* resume agent
* suspend agent
* terminate agent
* terminate service
* show agents (nicely formatted output)
* list agents ('|' and CR delimited output)
* show services (nicely formatted output)
* list services ('|' and CR delimited output)
* shutdown
* restart platform
* start/stop/restart service (not sure about this)
now have a simple plugin that provides a test version of these commands
(with the exception of the last 2 of them) and will start work on a sample
gui
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
|
|
From: Terry L. <ter...@gm...> - 2004-09-02 10:28:58
|
10 messages has been excluded from this view by a project administrator.
