> This kind of 'cooperating agents' model has been used successfully by
> several folks on this list (speak up, y'all). Because each engine can
> run in a separate thread simultaneously, you could potentially get
> better performance. The only difficulty would be with communicating
> information between engines; only you know how coupled your rule sets
> will be.
When I was in grad school I worked on a project called ICADS (Intelligent
Computer Aided Design System, I think) which used a distributed blackboard
to coordinate mulitiple instances of CLIPS engines running on one or more
networked computers. As the user created entities in a CAD package, the
system in the background would "consult" on the state of the drawing at hand
and point out any violations of constraints etc.
The system was built using a modified version of CLIPS 4.3 that included a
bbassert UDF. This UDF would, using sockets, connect to a "distributor"
which echoed the facts to interested parties (based on fact pattern(s) - not
all parties were interested in all bb facts so they would only get the
subset they wanted.)
I am planning to implement a similar approach but instead of using raw
sockets, I will use Jess objects (which can be distributed or not) that
represent "namespaces." Instead of a single blackboard, each Jess factlist
will represent a "namespace" and these can register to receive facts (again,
based on a pattern) from other registered (or well known) "namespaces."
> I haven't forgotten, by the way, the discussion we once had on the
> list about "modules"; look for them in a future release. I have a plan
> of attack.
I don't know how my usage of namespaces will fit into your usage of modules
but I believe that the namespace concept as I envision it will be more of a
"plumbing" thing and will be as transparent as possible to the language
itself (it's an environment thing, not a language thing - which is what
modules are...)
The biggest differences are efficiency, performance, and deployment.
Namespaces, as I will implement them, will be very loosely coupled and can
exist with or without each other (and could be used/created by third parties
who know very little about each other) but will have the drawback that they
will require separate Jess instances (and cannot share factlist and/or
symbol table entries.)
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
