Yes, for our drools-repository versioning, we are having pretty strong versioning.
As for security, we will have that (eventually) - JCR supports a variety of security models, but it can be locked down as much or as little as needed. Feel free to jump in ! I will have more of a read of your comments later tonight., some interesting points (and new possible features). On 11/29/06, Arjun Dhar <[EMAIL PROTECTED]> wrote:
Mark Proctor <mproctor <at> codehaus.org> writes: > > Drools 3.0 <http://labs.jboss.com/portal/jbossrules> the project is > about to be released and with that we will create a branch for JBoss > Rules 3.0 the product. JBoss Rules 3.0 will be a long lived stable > branch packaged with JBoss support and training goodness. > > Some of the Drools project developers have got together and produced an > initial brain dump -- a "wish list" for future development - which will > form the basis of our Road Map > <http://wiki.jboss.org/wiki/Wiki.jsp?page=DroolsRoadmap>. This should > help users understand the direction we wish to take Drools. Obviously > this goes well beyond the scope of a next release and we will start to > prioritize the work soon. The assigned names are just initial first > owners, ownership will more than likely change over time. Some will ask > "what about integration with X" - several of the features in the list > are there to assist integration with projects like jBPM and Seam, e.g. > backward chaining and named facts. As always in OSS I'm sure there will > be surprised additions that surface, that are not in the list. > > Feedback Welcome :) > > *Rule Engine* (mark) > parser extensions for rule additions are handled by michael and bob, > builder extensions by mark > > * Backward Chaining (mark) > * Connective field constraints (mark) > * subfield references (mark) > * Nesting of Conditional Elements inside 'not' and 'exists' (mark) > * Shadow Facts (michael) > * 'forall' first order logic support (edson) > * 'accumulate' first order logic support (edson) > * Logical field modifications (mark) > * Optional functional calls only (michael) > * Improved Performance (edson) > * Possible Leaps/Rete design re-use - from our ultra fast > experimental Leaps implementation (alex) > * Event Management (edson) > * Concurrent/Asynchronous API (mark) > * Templates (mark) > * Improved autoboxing (mark/mic) > * Improved no-loop support (mark) > * Named facts (mark) > * Alternative equals map instead of identity - for duplicate facts > (edson) > > *Eclipse IDE* (kris) > > * Interactive debugger with breakpoints (kris) > * Context assist for Column types and field names (kris) > * Context assist for java expressions and blocks (kris) > * Field Type aware widgets - dates, boolean (kris) > * In-place field Type validation (kris) > * Folding support (kris) > * Refactor support (kris) > * Improved Audit Event Listener (kris) > * Improved line number error reporting for code blocks (kris) > * Drools perspective, to start making a single perspective for all > future UI work (kris) > > *Parser* (bob) > > * Modularization (bob) > * Better error detection and reporting (bob) > * Possible parser split - meta driven light weight IDE parser, rule > builder parser. (bob) > > *Natural Language* (michael) > > * API driven naturual language mappings for classes and fields (bob) > * DSL enhancements: Type aware/constrained DSL expressions (kris) > > *Management* (michael) > > * Rule Repository (michael) > * Deployment management (michael) > * Effective Dated rule management via JMS (michael) > > *Standard Support* (michael) > > * Drools API and Language support for 3rd party engines. (mark) > * RuleML (michael) > * HRML (michael) > > *Misc* > > * Alternative language support for expressions and blocks - Groovy, > Javascript.(mark) > * Decision Trees (mark) > * Fuzzy Logic (mark) > * Constraint programming (mark/michael) > * Web based DSL rule authoring (mayavi) > * Application Server integration for new RuleBase/WorkingMemory via > JMX or equivalent (mark) > * FIT (michael) > > -------------------------------------- Date: 29th Nov 2006 Hi, from a business perspective there are some additional requirements that need to be addressed. I'll keep this short :) ..If a company is looking to maintain its rules at a central repository, then two aspects become very important: 1. Security 2. Versioning Security --------- The state of the rules persisted such be such that it cannot be read if protected. Currently, a DRL file saved on eclipse does not provide this feature. Technically I'm looking at building the following; if you guys do it,..all the more better: (Basic requirements) 1.1. Save in encrypted format 1.2. On opening ask for key to decrypt file 1.3. Disable copying of text from .Drl/DSL editor to any other application ...goes without saying that in additon, that if a person wishes to use a non- eclipse base IDE then the packages can be re-used. Versioning ---------- While one can argue that simply putting, these files on a versioning system takes care of it. There needs to be inherent support for versioning by the system. No where in the DRL file can I specify a version; so that during runtime I can obtain that information about the file. Work arounds can be coded, but there should be standard support. e.g. A company has a rule in 2002 on some loan policy; In 2004 the rule is ammended but the people with loans before 2004, the previous version of the rule would continue to apply indefinitely. I know the work around to this, but wouldnt it be nice (Yes: Nice to Have priority), if the Rule engine could keep both versions active for us in the working memory and we can determine at runtime which version to use instead of adding date conditions all over the rules in the DRL file. It's easier to manage, and we all know how important that is to us! :) ..In additon the the above important requirements here is a WISH LIST:: a. Allow mutual exclusion of rule-sets or even agenda groups (in addtion to the ME of only rules currently using Activation-Group). A mutually excluded agenda group may not regain focus even if auto-focus is on. Reason:: A company servicing multiple clients, can play with existing rules/sets by simply changing these attributes and customizing what parts may or may not be applicable. b. Allow rules to belong to multiple activation groups. Reason: Groups can have intersections; and an intersection implies a rule that belongs to two or more activation groups. c. Agenda sub-groups Reason: This can be an alternative to 'b'. Defining new groups from existing ones can accomplish what 'b' wishes to, in addition to that any activity of a Group would apply to all its memebers in the sub-group making this a powerful feature. thanks, Arjun Dhar (Engineer & Consultant) --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
