oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

On Thu, 2009-03-26 at 22:18 +0100, Francesco Garosi wrote:

> 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.
> 

This seems to be a sensible approach.

> 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.


You may or may not know that OSHIP has an Event System.  So in this case
even though it is a web based system, it does have state. It is a
complete application server not just a web publishing environment. Plus
you can inherit from the event system to create your own states.  Does
that help?

Cheers,
Tim

Attachment: signature.asc
Description: This is a digitally signed message part