Would it be possible for folks to join tomorrow the 16th at 2pm EST? I fear that some people will be missing next Wednesday due to the US holiday on Thursday the 24th.
Tammy? Dave? Mike? Darius? Burke? Roger? Win? Beuller? https://wiki.openmrs.org/display/RES/Design+Forum Ben On Mon, Nov 14, 2011 at 8:55 PM, Burke Mamlin <[email protected]>wrote: > Can we enumerate what we want from the simplified logic service? > > - Existing logic engine can be implemented as an optional module > without too much trouble. > - Strongly instead of loosely typed results. > - Support for parameters. > - ... > > Do we want to support an index date (i.e., avoid assuming today's date)? > > Don't we want to forego tokens? Or are we assuming that consumers of > logic know which rule provider to consult (which may or may not use > tokens)? If the consumer needs to know which provider to consult and that > provider will presumably be handling the evaluation, then what purpose does > the logic service serve? Alternatively, rule providers could be registered > with the logic service and then consumers could come to the logic service > with a token (i.e., not need to know the provider). > > I'm assuming that we'll defer caching & criteria implementations to the > various forms of logic (at least for now). > > What's the purpose of LogicContext now? In the original design, > LogicContext served a few purposes: (1) proxy for all data requests by > rules, (2) provide a context for evaluations – index date & parameters – > that could be stacked for recursion, (3) context for caching results, and > (4) an abstraction so that the same rule could be run against a patient or > cohort. If we aren't using logic context for any of these, do we need to > maintain LogicContext at this stage? > > Looking forward to the design call. > > Cheers, > > -Burke > > On Wed, Nov 9, 2011 at 10:23 PM, Michael Seaton <[email protected]> wrote: > >> ** >> Hi all, >> >> I wanted to pick up a thread on the future of Logic that we spent some >> time discussing during the Developers Forum on October >> 27<https://wiki.openmrs.org/x/5oamAQ>. >> >> >> The overall consensus on the call was that *"Logic is too complicated. >> We wish there were a simpler implementation, that were easier to adapt to >> individual needs. We wish it were more rigorously tested, including >> performance testing"*. >> >> *Anyone that cares about preserving Logic as it currently exists, or >> wants to see it change in a specific way, please read further* >> >> Specific users of Logic have communicated the following needs: >> >> - Tammy and her team require more control over the current Logic >> implementation, and better testing around it, so that future upgrades do >> not cause serious bugs and performance degradation >> - Win and Tammy need implementations of Logic that are optimized for >> running lots of rules for individual patients at a time >> - Mike needs an implementation of Logic that is optimized for running >> a single rule for lots of patients at a time as well >> - Mike wants to be able to choose to not use the existing Logic >> implementation in favor of an implementation provided by the Reporting >> module >> >> To accomplish this, the following high-level refactoring steps are being >> considered: >> >> - Reduce and simplify the number of interfaces and interface methods >> that Logic exposes in OpenMRS core >> - De-couple the existing Logic Module in such a way that it is one of >> many possible "Rule Providers" that can plug into this lighter-weight core >> framework >> - Remove, if possible and practical, the need to have a "required" >> Logic module installed >> >> Specifically, we are considering an approach that would reduce the core >> Logic interfaces to something like: >> >> interface LogicContext; >> >> interface Result; (classes DateResult, NumberResult, ListResult...) >> >> interface Rule { >> Set<RuleParameterInfo> getParameterInfo(); >> Class<? extends Result> getReturnType(); >> Result evaluate(Integer patientId, Map<String, Object> parameters, >> LogicContext context); >> } >> >> interface LogicService { >> public Result evaluate(Rule rule, Patient patient, Map<String, Object> >> parameters, LogicContext context); >> public Map<Integer, Result> evaluate(Rule rule, Cohort cohort, >> Map<String, Object> parameters, LogicContext context); >> } >> >> I would like for this to spur the following potential activities: >> >> - Give anyone who has not yet been aware of these discussions, or who >> does not agree with this approach, an opportunity to weigh in and get >> involved in the process >> - Make a plan to put this topic onto one or more future Design Forum >> calls, in order to agree upon the revised design, make tickets, and >> establish an owner for moving it forward. >> - Publicize when this Design Forum will occur so that interested >> parties can be involved as desired >> >> Thanks! >> Mike >> >> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
