Re: [rules-dev] refactoring for a knowledge oriented product
by Christine
> There is nothing planned for 5.0 beyond rules, processes and cep. But
> yes I'd like to see other things be included, if they
> can be integrated and unified in a meaningful way.
I was thinking of a blackboard. That's simple to implement yourself, but
it would be convenient to have it in Drools.
Christine
17 years, 5 months
Re: [rules-dev] refactoring for a knowledge oriented product
by Christine
> I'm just doing a brain dump of how I think I'd like to see the 5.0 api
move, where we move from a rule oriented framework to a knowledge
oriented framework for rules and processes.
sounds interesting. how exactly do you see processes, integrated in the
knowledgebase, other than just calling ordinary java classes in the then
part of a rule? Will there be support for other AI-type algorithms?
Christine
>
> A rough namespace and interface mapping could be as follows:
> org.drools
> KnowledgeBase <- RuleBase
> StatefulKnowledgeSession <- StatefulSession
> -extends both RuleSession and ProcessSession
> -in theory someone could have a rule or process specific impl
> although we will continue with the combined approach for now
> StatelessKnowledgeSession <- StatelessSession
> RuleSession
> -contains the rule specific api from WorkingMemory
> ProcessSession
> -contains the process specific api from WorkingMemory
> org.drools.events
> org.drools.knowledge.defintions
> KnowledgeDefinitionPackage <- Package
> -Possible just KnowledgePackage
> but I like reinforcing that these are definitions
> org.drools.knowledge.defintions.rules <- org.drools.rule
> org.drools.knowledge.defintions.processes
> org.drools.knowledge.defintions.models
> -will eventually contain our ontology stuff
> org.drools.knowledge.defintions.models.facttemplate <-
> org.drools.factemplates
> org.drools.knowledge.defintions.models.pojo
> -our current pojo model stuff should probably go here too
> org.drools.knowledge.engines.rules <- org.drools.reteoo (and common,
base, spi etc which will also be refactored)
> org.drools.knowledge.engines.processes
>
> We will create a drools-api module. This will contain all public user
apis for all modules in the project, which will allow us to support
service frameworks better, such as OSGi. This will also allow us to more
easily differentiate from public stable apis and internal apis.
>
> To get compability with 4.0.x we'll have a drools4-adapter jar, which
will keep all the 4.0 names and just wrap and delegate to the new impl.
We won't be able to achieve 100% api comptability, but we should be able
to for all the most common public apis.
>
> Mark
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
17 years, 5 months
refactoring for a knowledge oriented product
by Mark Proctor
I'm just doing a brain dump of how I think I'd like to see the 5.0 api
move, where we move from a rule oriented framework to a knowledge
oriented framework for rules and processes.
A rough namespace and interface mapping could be as follows:
org.drools
KnowledgeBase <- RuleBase
StatefulKnowledgeSession <- StatefulSession
-extends both RuleSession and ProcessSession
-in theory someone could have a rule or process specific impl
although we will continue with the combined approach for now
StatelessKnowledgeSession <- StatelessSession
RuleSession
-contains the rule specific api from WorkingMemory
ProcessSession
-contains the process specific api from WorkingMemory
org.drools.events
org.drools.knowledge.defintions
KnowledgeDefinitionPackage <- Package
-Possible just KnowledgePackage
but I like reinforcing that these are definitions
org.drools.knowledge.defintions.rules <- org.drools.rule
org.drools.knowledge.defintions.processes
org.drools.knowledge.defintions.models
-will eventually contain our ontology stuff
org.drools.knowledge.defintions.models.facttemplate <-
org.drools.factemplates
org.drools.knowledge.defintions.models.pojo
-our current pojo model stuff should probably go here too
org.drools.knowledge.engines.rules <- org.drools.reteoo (and common,
base, spi etc which will also be refactored)
org.drools.knowledge.engines.processes
We will create a drools-api module. This will contain all public user
apis for all modules in the project, which will allow us to support
service frameworks better, such as OSGi. This will also allow us to more
easily differentiate from public stable apis and internal apis.
To get compability with 4.0.x we'll have a drools4-adapter jar, which
will keep all the 4.0 names and just wrap and delegate to the new impl.
We won't be able to achieve 100% api comptability, but we should be able
to for all the most common public apis.
Mark
17 years, 6 months
Licensing impact on BRMS 2.0 due to Ext JS library moving from LGPL to GPL?
by Shahad Ahmed
The front-end of the BRMS destined for Drools 5 appears to use the GWT-EXT
library, which in turn requires the Ext JS library. However, one of my
colleagues has pointed out that as of April 21st 2008, the EXT JS library is
now licensed under GPL (v3), whereas prior to this it was licensed under
LGPL.
I don't know too much about licensing, but isn't this going to have an
impact on the final Drools 5.0 licensing? From the little I know about
licensing, if you use a GPL library (ext-core.js etc in the BRMS) then any
derived code (e.g.. Drools) can only be distributed under GPL as well,
so Drools couldn't be distributed under Apache 2 anymore?
Its a bit bonkers of EXT JS to suddenly change a license from LGPL to GPL
and there is definitely a "heated" debate going on in the GWT-EXT and other
forums. I hope it's appropriate to post this on the dev list, and apologies
if not.
Regards
Shahad
17 years, 6 months
synchronization between jboss\jbrms and eclipse\drool
by brahim el achbor
Hi all,
I'm a student doing my internship in an IT enterprise, the subject of this
internship is to evaluate JBoss Rules, and see if it can replace ILOG Jrules
in some of our client's projects
One important thing that can make Jboss Rules eligible is to have the
possibility of synchronization between jboss\jbrms and eclipse\drool: this
means to be able to access the Eclipse based rules project through the Jboss
BRMS, and to be able to edit the rules and sync after the changes...
Is that possible with the current version of Drools?
Thank you very much for any help you can give me. (and sorry for my terrible
english !!!)
Brahim EL ACHBOR
17 years, 6 months
