oship-dev team mailing list archive

[Francesco Garosi <franz@xxxxxx>]

Hello Everyone!

As a matter of coding style, I'd suggest to avoid using the top level 
environment (the one that's implicitly created by both CLIPS and 
PyCLIPS) for production purposes; instead in all PyCLIPS related 
applications an explicitly built Environment object should be used, 
possibly named with a prefix . For instance, in an EpiS3 related 
application (say "a1"), a module prologue could be something like the 
following:

[CODE]
import clips
EpiS3_a1 = clips.Environment()
EpiS3_a1.Load("a1_baserules.clp")

# rest of the module follows...
[/CODE]

Of course another prefix (instead "EpiS3_", that is quite a long one) 
can be chosen, as long as we explicitly create an environment in the 
applications.

The reason why I'm suggesting this is that in the next major version of 
PyCLIPS the top-level environment is scheduled for deletion, and this 
behaviour is going to be mandatory. If we adopt this style from now, it 
will save us a lot of typing when PyCLIPS 2.0 is going to be the most 
favourable option.

There are other problems to talk about working on the OSHIP platform. 
Probably the first thing to discuss is how a stateful system like 
CLIPS/PyCLIPS can cope with the implicit statelessness of a web based 
environment. Probably the PyCLIPS team should work on two main threads: 
the former is about the actual rule system (that is, finding a structure 
for the rules that will build the decision system), while the latter 
should concentrate on the integration of the underlying CLIPS system in 
a way that can keep the state (CLIPS working memory) with the web server 
working in an almost stateless way as usual.

Let me know what you think about these remarks.

Cheers,

F.


--
>>@
Risposte/Replies :
Francesco Garosi
  Office: <f.garosi@xxxxxxxxxxxxxxx> (++39/0577/536937)
  Home: <franz@xxxxxx> (++39/0577/47806)
  Web: http://www.jks.it/