Hello again, in any case, if we implement it as a plugin we are still open. We could have a I_RulesEngine and let our plugins implement it. We could then have a jeops based plugin, a javascript plugin (I agree that a user should not need to learn a new language each time) or a tcl plugin or what more ... and then we can start flight ....
Salutissimi Michele > -----Urspr�ngliche Nachricht----- > Von: Marcel Ruff [mailto:[EMAIL PROTECTED]] > Gesendet am: Dienstag, 23. April 2002 09:18 > An: [EMAIL PROTECTED] > Betreff: Re: AW: [xmlblaster] Rule Based Publishing > > [EMAIL PROTECTED] wrote: > > I had a (very) quick look at jeops and from a first glance > it looks pretty similar to jrules (a commercial product). > > Making the choice of using it instead of javascript (or even tcl) > could suddently transform xmlBlaster > > into a rules engine or even a complete workflow engine. > > This would broaden the application possibilities of > xmlBlaster even more > > (I just saw what telecom companies are spending in > workflow engines). > > > > So I think it might be interesting to give a closer look at jeops. > > > > Saluti > > Michele > > Saluto, > > some thoughts about the rule engine JEOPS > http://www.di.ufpe.br/~jeops/ > > > JEOPS: > ====== > > /** > * Simple rule for trading. > */ > rule trade { > /* In this rule, one agent will buy a product from another > agent. */ > declarations > Salesman s; > Customer c; > Product p; > conditions > c.needs(p); // he won't buy junk... > s.owns(p); > s.priceAskedFor(p) <= c.getMoney(); > actions > s.sell(p); > c.buy(p); > } > > > Javascript: > =========== > > boolean trade(s, c, p) > { > if (c.needs(p) && s.owns(p) && s.priceAskedFor(p) <= > c.getMoney()) { > s.sell(p); > c.buy(p); > } > } > > I prefere the Javascript approach, every teenager pupil > knows the syntax (from developing his homepage), the > customer of the product does not need to learn a new > language ... > > The next point is we often have to deal with time: > > > boolean trade(s, c, p) > { > if (c.needs(p) && s.owns(p) && s.priceAskedFor(p) <= > c.getMoney()) { > tm.waitForCreditClearance(); // has buyer money > s.sell(p); > sleep(10000); // bank earns interest rate > c.buy(p); > } > } > > or "if terminalserver has delivered more than 100 bytes > over the last minute and the last byte is not older than 10 sec" > is a very timing based rule with history information. > > > Another point is the dynamic on the fly change of rules > in a hot running system. > does JEOPS support this? > > ===================== > > On the other hand we could compile the JEOPS rule java classes > on the fly, and probably gain some performance when > executing 1 million times. > > JEOPS defines a "Knowledge base" which fits very nice to > xmlBlaster, our message approach keeps the "Knowledge Base" > up to date in 'real time' -> a real gain of value. > > Native workflow/rule support in xmlBlaster would be a real > gain for xmlBlaster, we should follow this track. > > Did i miss the point? > > Marcel > -- > Marcel Ruff > mailto:[EMAIL PROTECTED] > http://www.lake.de/home/lake/swand/ > http://www.xmlBlaster.org > >
