a guest Apr 27th, 2018 231 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. <conan> but hen  also from a consequence
  2. <mfusco> conan, I just don't see a practical use case tbh
  3. <conan> send and receive?
  4. <conan> you dont think an application needs to send message ?
  5. <mfusco> sending a message to a node, yes
  6. <conan> and receive and process the results?
  7. <mfusco> an entire application yes
  8. <mfusco> mmm, 1 min let me reread what you wrote, I guess I misunderstood you
  9. <conan> mfusco  imagine for instance I want to have one rule that handles all responses first.
  10. <conan> so lots of consequences submitting async tasks, or messages.
  11. <conan> I setup one receive node, and everything goes through that.
  12. <conan> end of the day, all we are doing is allowing something external to insert directly into a node and continue propagation - instead of inserting into the working memory.
  13. <conan> and done in a thread safe and efficient way
  14. <mfusco> what's the diff in inserting into the ksession? (or an EP)?
  15. * paulovmr (~paulovmr@redhat/jboss/paulovmr) has joined
  16. * ChanServ gives voice to paulovmr
  17. <conan> mfusco  you'd probably code up snd/rvc nodes in a day - if we leave our DRL.
  18. <conan> it would be worth doing
  19. <conan> just to check canonical model is "good enough"
  20. <conan> and it would start to make you think about reactive programming models more :)
  21. * evacchi (evacchi@nat/redhat/x-ikcyuibtjxltonys) has joined
  22. <jbossbot> git [drools-website] push master bca2d34.. Michael Biarnés Kiefer New menu (#67)...
  23. <jbossbot> git [drools-website] push master URL:
  24. * conan has quit (Quit: Computer has gone to sleep.)
  25. * cchianel is now known as cchianel|mtg
  26. * tsurdilo (~tsurdilo@2600:1700:3d70:c50:8585:deb6:f8c7:b3b8) has joined
  27. * mbarkley ( has joined
  28. * michaelbk has quit (Remote host closed the connection)
  29. * cimbalek has quit (Ping timeout: 240 seconds)
  30. * michaelbk (mbiarnes@nat/redhat/x-kaqxslyptabyqzem) has joined
  31. * tdavid (tdavid@nat/redhat/x-aepowjmtvufimowk) has left
  32. <jbossbot> git [droolsjbpm-integration] push 7.7.x 3913b2b.. Maciej Swiderski JBPM-7190: filter parameter is not a required param in Swagger definition. (#1449) (#1451)
  33. <jbossbot> git [droolsjbpm-integration] push 7.7.x URL:
  34. <jbossbot> jira [JBPM-7190] Filter parameter in RuntimeDataResource.getProcessesByFilter is not required [Pull Request Sent (Unresolved) Bug, Major, KieServer, Maciej Swiderski]
  35. * cwatkins (~cwatkins@ has joined
  36. * ederign (ederign@redhat/jboss/ederign) has joined
  37. * ChanServ gives voice to ederign
  38. <mfusco> etirelli, can you please pm_ack this?
  39. <jbossbot> jira [RHPAM-795] Deadlock in Drools ProjectClassLoader when starting Business Central [Pull Request Sent (Unresolved) Bug, Blocker, Business Central, Mario Fusco]
  40. <etirelli> mfusco: done
  41. <mfusco> etirelli, thx
  42. * cwatkins has quit (Quit: Leaving)
  43. * jhrcek has quit (Quit: Leaving)
  44. * ddoyle ( has joined
  45. <dzonca> etirelli: I looked at
  46. <jbossbot> jira [RHDM-181] Not possible to use Stateless session in Test Scenarios [New (Unresolved) Enhancement, Critical, Decision Central, Daniele Zonca]
  47. <dzonca> did you assign to me that item just to remember in the new implementation to support Stateless Session or do you want I try to fix also in the current one?
  48. <etirelli> dzonca: this is just to "remember" to fix it in the new editor... not fix in the current one
  49. <dzonca> ok
  50. <etirelli> dzonca: it is waste of time changing the current one
  51. * cchianel|mtg is now known as cchianel|wfh
  52. * cimbalek (mcimbale@nat/redhat/x-xlpjoqbrthpofvmk) has joined
  53. <dzonca> etirelli:  at the same time if we want to support Stateless and Statefull in the new implementation we will probably need to change a lot the fluent API because KieSession and StatelessKieSession are almost completely different
  54. * maciejs has quit (Quit: Leaving.)
  55. * cchianel|wfh is now known as cchianel|wfw
  56. * cchianel|wfw is now known as cchianel
  57. * viyengar (~viyengar@ has joined
  58. <ederign> tzimanyi mfusco ping
  59. <tzimanyi> ederign Hi
  60. <ederign> tzimanyi hi! any news about ?
  61. <jbossbot> git pull req [drools] (open) Tibor Zimanyi RHPAM-795 RHPAM-55 Register project classloaders as parallel capable
  62. <jbossbot> jira [RHPAM-795] Deadlock in Drools ProjectClassLoader when starting Business Central [Pull Request Sent (Unresolved) Bug, Blocker, Business Central, Mario Fusco]
  63. <jbossbot> jira [RHPAM-55] Java-level deadlock after cloning a repository [New (Unresolved) Bug, Critical, Business Central, Eder Ignatowicz]
  64. <tzimanyi> ederign I think it is waiting for merge
  65. <ederign> tzimanyi mfusco this is probably related with
  66. <jbossbot> jira [RHPAM-55] Java-level deadlock after cloning a repository [New (Unresolved) Bug, Critical, Business Central, Eder Ignatowicz]
  67. <tzimanyi> ederign yes, I linked that in the PR name
  68. <ederign> tzimanyi mfusco do you think it will make it for friday?
  69. <tzimanyi> ederign not sure, depends on mfusco opinion
  70. <mfusco> ederign, tzimanyi, sorry in a meeting
  71. <mfusco> reading
  72. <tzimanyi> mfusco I will prepare the backport to 7.7.x, is it ok?
  73. <mfusco> ederign, yes I just have to merge tzimanyi's fix, I'll do before EOD
  74. * viyengar has quit (Ping timeout: 240 seconds)
  75. <mfusco> tzimanyi, not necessary, I'll cherry-pick your commit
  76. <mfusco> tzimanyi, thanks
  77. <ederign> mfusco great thank you!
  78. <tzimanyi> mfusco ok thanks
  79. <ederign> tzimanyi thanks!
  80. <ederign> tzimanyi do you want to have PAM-55 assigned to you?
  81. * mbarkley has quit (Ping timeout: 248 seconds)
  82. <tzimanyi> ederign not needed, just resolve it when merged
  83. <tzimanyi> and link the backport commit
  84. <ederign> tzimanyi ok!
  85. * conan (~conan@ has joined
  86. * egonzale (~egonzalez@ has joined
  87. * wmedvede has quit (Quit: Leaving)
  88. * wmedvede ( has joined
  89. * lclayton1 (lclayton@nat/redhat/x-iaohchzjcxisnygi) has joined
  90. * mweiler has quit (Quit: Leaving.)
  91. <conan> mfusco  back
  92. <conan> mfusco  anyway a send/rvd node will take only a few hours - if we do it at hte model level.
  93. <conan> its' really very simple.
  94. <conan> mfusco  when you want to attempt it, let me konw. I'll talk you through it.
  95. <conan> mfusco  we already have the basis for this. via the TimerNode.
  96. * ksuta (ksuta@nat/redhat/x-uxgnkygfwqtfjwpj) has joined
  97. <conan> it's just a variant of this
  98. <conan> the send is a variant of the 'from' node
  99. <conan> the receive a variant of the timer node
  100. <conan> we can do both purely at the model level
  101. <conan> mfusco  it will be actually quite cool to do. and will bring value for drools to thread safe reactive programming models.
  102. * michaelbk has quit (Quit: Leaving)
  103. <mfusco> conan, the send/rcv node is a EPN?
  104. <dzonca> conan: you told me about support units in API
  105. <conan> no
  106. <conan> not really
  107. <conan> mfusco  EPN is different.
  108. <dzonca> I read about them in the documentation, what's your idea?
  109. <conan> mfusco  it's are chains of engines. And you setup "queries" that select and forward data to the next node.
  110. <conan> so every node has a process, selection and forward phase.
  111. <conan> process the incoming data, select data for forwarding with queries.
  112. <conan> mfusco  but that's something we should do
  113. <conan> crazy we haven't done it yet
  114. <conan> it's so trivia lt do now
  115. <conan> we just need to make sure the usage pattern works well for drools
  116. <conan> figure out the batching
  117. <mfusco> thinking
  118. <conan> mfusco  the idea with an EPN is to maximise the over all throughput
  119. <conan> but you don't always konw at what rate stuff comes in
  120. <conan> that and ofcourse do splits and joins
  121. * jomarko has quit (Quit: Leaving.)
  122. <conan> so you split data, to a fan out of processors, select and forward o the joiner.
  123. <conan> well after the split, it can still go through a chain of procssors, until it does the join.
  124. <conan> not everything is always piped forward
  125. <conan> you have an "event cloud"
  126. <mfusco> processors == filters ?
  127. <conan> so any node in the EPN can detect a composite event, and publish to the event cloud
  128. <conan> mfusco  a processor here is just a normal drools rule
  129. <conan> it's going to select and act on data
  130. <conan> so imagine a "node" has two aspects to it
  131. <conan> one is just a normal drools rule. that processes isnerted data - select/filtering and executing actions. then the next phase is to use queries to select what is to be forwarded.
  132. <conan> now if you keep this stateless, and only working on a single object type - it's very trivial.
  133. <conan> but you cannot guarantee that
  134. <mfusco> no joins?
  135. <conan> well it can
  136. <conan> I'm just talking about the simplest use case
  137. <conan> which is valid
  138. <mfusco> ok
  139. <conan> some organisations will not have joins
  140. <conan> others will
  141. <conan> and with those jions, data can come from two places
  142. <conan> either via the pipeline - like any other data - or "background" data, that is loaded into the engine.
  143. <conan> like lookup data
  144. <conan> so you can pre-popualate an engine with data that is used ot help process date going through the pipeline
  145. <conan> dzonca  hi, yes sorry. mis conversation :)
  146. <conan> s/mis/mid/
  147. <conan> dzonca  make it work for units.
  148. <conan> dzonca  and edson says, make it work for stateless.
  149. <conan> dzonca  there is a separate aspect, we never made units work on stateless yet.... :)
  150. <conan> dzonca  look at docs and unit tests, to see units.
  151. <mfusco> conan, will you be at Summit? can we please rediscuss it there? I'm a bit lost :)
  152. <conan> mfusco  how? it's soooo easy :)
  153. <conan> evacchi  ^ you following the scroll?
  154. * mczernek_ has quit (Ping timeout: 255 seconds)
  155. <conan> evacchi  two topics. back to the prova snd/rcv nodes. but separately what an EPN is.
  156. * marekn (mnovotny@nat/redhat/x-kmiqyuhtlbvkvxaf) has left
  157. <conan> mfusco  we could just model the whole thing locally first too.
  158. <conan> it's just an example
  159. <evacchi> dzonca: prova is
  160. <jbossbot> Title: Prova language for rule based scripting of Java and agents, and knowledge and information integration
  161. * etirelli has quit (Ping timeout: 260 seconds)
  162. <conan> mfusco  maybe we should just do that. setup a model for chaining pipelines on a machine - you can just do in separate threads.
  163. <conan> mfusco  just as a learning exercise.
  164. <evacchi> trying to see the connection between EPNs and snd/rcv
  165. <conan> can simulate the whole thing as just a usage pattern, on a local machine. before going machine distributed.
  166. <conan> mfusco  but either way I'd start with the snd/rvc node
  167. <conan> because I've probably spent more time epxlaining it, than it would take to do :)
  168. <conan> mfusco  it is deceptively simple. we already have the foundations in the nodes for this.
  169. <conan> mfusco  want to do it tomorrow? :)
  170. <mfusco> conan, I need to finish customer's use case for executable model, but almost done
  171. <conan> ok
  172. <mfusco> conan, yes, I could give it a try tomorrow
  173. <conan> ping me. lets do this, it won't take long. just to get it out of the way.
  174. <mfusco> conan, but first I need to reread prova docs
  175. <conan> you don't need to read all of it
  176. <conan> just the snd/rvc
  177. <mfusco> conan, yes, that bit, I'm not fully understanding
  178. <conan> but I can talk you through it too
  179. <conan> as in specifically not to impl.
  180. <conan> 1) 'from' can already execute any code. So have 'from' snd a message, the result is just a single object (the correlation id). 2) next node is variant of the timer node. The correlationId is on the left input. When the message returns, the node picks it up (in a thread safe manner, as per TimerNode) and does the join and continues.
  181. <conan> that's it
  182. <conan> we do exactly the same thing to correlate a Timer Node with the job.
  183. <conan> mfusco  that's the basic, first iteration.
  184. <conan> mfusco  simples :)
  185. <conan> you can even just use a 'from' node for the first iteration, nothing extra needed for the snd. We can optimise it later.
  186. <conan> mfusco  getthing that so far?
  187. <conan> mfusco  what it means is we can have distributed reactive programming, without blocking network evlauation while we wait for the message to return.
  188. <conan> a simple use case.
  189. * dgutierr_ ( has joined
  190. <conan> mfusco  lets say a "join" needs remote lookup data, this takes time, we don't want to wait on it.
  191. <conan> so this way the 'join' can request what it needs, and will continue once it has it - without blocking/wait code.
  192. <conan> mfusco  that's your first use case :)
  193. <mfusco> the timer is not really a timer, is just for async exec, right?
  194. <conan> mfusco  no there is no timer.
  195. * etirelli ( has joined
  196. * etirelli has quit (Changing host)
  197. * etirelli (~etirelli@redhat/jboss/etirelli) has joined
  198. * ChanServ gives voice to etirelli
  199. <conan> mfusco  but the TimerNode shows you how an external thread can safely inject data into a node, and signal for that node to be evaluated. all in a thread safe manner.
  200. <conan> that's the key
  201. <mfusco> ok, getting it now :)
  202. <conan> and it shows off the value of our state machine
  203. <mfusco> so this works on the timer thread of the state machine
  204. <conan> so that we can do really efficient correlated async operations, while still having a single thread engine.
  205. <mfusco> now I see
  206. <conan> mfusco  well not necessarily the timer thread
  207. * dgutierr has quit (Ping timeout: 276 seconds)
  208. <conan> it would be it's own thread
  209. <conan> it would just use the same concept
  210. <conan> the timer after all is just some external thread, that eventually wants to shove something into a node.
  211. <mfusco> I mean a thread coordinated by the state machine as it already happens with timers
  212. <conan> so we should allow other threads to do the same
  213. <conan> mfusco  you can do this generically.
  214. <conan> so that anyone that implements an interface, can have an external async processor that can have thread safe co-ordination with a join node.
  215. <conan> it would allow people to plugin anything they want
  216. <conan> JMS is jsut the first example
  217. <conan> but it should be provider based
  218. * tbento is now known as tbento_afk
  219. <conan> mfusco  making more sense now?
  220. <mfusco> conan, ok, I just need to reread prova docs, but now it's clearer
  221. <mfusco> yes
  222. <conan> told you it's simples!!!! :)
  223. <conan> it's probalby how I describe it
  224. <conan> but we've spent more time talking about it
  225. <conan> than it'll take to do
  226. * etirelli has quit (Client Quit)
  227. <conan> always put it off before, as it would be a pita for DRL.
  228. <conan> but with canonical model, we can POC this stuff fast.
  229. <conan> and have full working examples
  230. <mfusco> ok
  231. <lclayton1> anbaker, dzonca: do you guys have any time for a quick chat?
  232. <conan> mfusco  we may be able todo this better.
  233. <conan> such that we make a base node
  234. <conan> extracted from TimerNode
  235. <conan> and then TimerNode can just extend that
  236. <conan> and we do another one that extends it, for user provided external.
  237. <conan> mfusco  look at TimeNode. scheduleTimer.
  238. <conan> now if oyu remove all the logic about hasNextFireTime etc - which is timer specific
  239. <conan> the meat to the co-ordination is
  240. <conan>             DefaultJobHandle jobHandle = (DefaultJobHandle) timerService.scheduleJob( job, jobCtx, trigger );
  241. <conan>             leftTuple.setContextObject( jobHandle );
  242. <mfusco> yes
  243. <dzonca> lclayton1: I will be back in 10 minutes
  244. <conan> so instead its leftTuple.setContextObject( asyncService.submit( ctx ) )
  245. <conan> and then the rest of how it co-ordinates the finished job, to continue with the correlaed join.
  246. <conan> that part is 100% identical.
  247. <mfusco> true
  248. <mfusco> so this is the receive part
  249. <conan> I would just clone timernode to start with
  250. <conan> remove the timer bits
  251. <conan> get it working
  252. <conan> then generify to a base shared node after
  253. <mfusco> what is the send?
  254. <conan> for this iteration you can use 'from' as is
  255. <mfusco> got this
  256. * tbento_afk has quit (Quit: This computer has gone to sleep. ZZZzzz…)
  257. <conan> just inject a variable that does the send
  258. <conan> it's a hack
  259. <conan> but quick
  260. <conan> we can improve later
  261. <conan> this pattern is for when there is specific correlation between a snd and subsequence rvc.
  262. <conan> but there are others
  263. <conan> if we "label" a received
  264. * karreiro is now known as karreiro_afk
  265. <conan> then any send (node) or consequence could submit something,that is received by a node in another rule.
  266. <conan> or even have a generic receive that receives everything
  267. <conan> you could also have a fanout on receivers, with the label approach.
  268. <mfusco> a publisher/subscriber?
  269. <conan> I guess in this case labels become like channels
  270. <conan> but I guess once step at a time :)
  271. <conan> mfusco  yes I think so.
  272. <mfusco> ok, sound a nice experiment
  273. <conan> mfusco you could setup a rcv node, directly on the end of a vert.x, to consume stuff.
  274. <mfusco> I'll finish with customer's PoC and then I'll give this a try
  275. <conan> only thing I can think though about vert.x
  276. <mfusco> yep, that could help also with vert.x intergration indeed
  277. <mfusco> I was thinking just the same
  278. <conan> with vert.x is it already taking care of the single threadedness?
  279. * mbarkley (~mbarkley@ has joined
  280. <mfusco> vert.x requires everything to be async
  281. <conan> i.e. by the time you attach your handler, you can assume it's guaranteed single threaded?
  282. <mfusco> so no, usually there are many threads involved
  283. <conan> ok
  284. <conan> just want to make sure vert.x is trying to handle some of the logic, that might be better handles via our state machine.
  285. <mfusco> I don't think so, but I need to check
  286. <conan> mfusco  we get this right. flesh it out enough. we can start to make a play for reactive programming models.
  287. <conan> our state machine is probalby fairly unique, for the complexity it can handle.
  288. <mfusco> yep
  289. <conan> mfusco  and then prmote it via projo rules.
  290. * cimbalek has quit (Ping timeout: 240 seconds)
  291. <mfusco> sorry, I need a coffee, I'll be back in 10
  292. <conan> anyoen doing vert.x, is using rxjava. so they'll be very happy with our pojo rules from us.
  293. <conan> mfusco  no problem,  I probably flooded your brains :)
  294. <conan> mfusco  so tets do this snd/rvc. once you understand that, we'll work through various use cases
  295. <conan> the EPN, we'll do another day.
  296. <conan> again this is not difficult, the basic versino - just usage pattern of drools.
  297. <conan> but I think we can probably do it better, by baking some things in - once we figure it out.
  298. <conan> I'm not sure what the answers are there, we need to research it via spikes.
  299. <conan> but i have ideas :)
  300. <conan> dzonca  sorry long scroll.
  301. <conan> dzonca  did mario provide you with link to units test cases?
  302. * ddoyle has quit (Quit: Leaving.)
  303. * ddoyle ( has joined
  304. * ddoyle has quit (Client Quit)
  305. * etirelli (~etirelli@redhat/jboss/etirelli) has joined
  306. * ChanServ gives voice to etirelli
  307. * ddoyle ( has joined
  308. * mhussain has quit (Ping timeout: 240 seconds)
  309. <conan> mfusco  prova also uses annotations nice as a "guard" model. The same thing can be simulated via facts. but using labels that can be targetted to allow or block evaluation, is a nice higher level thing.
  310. <mfusco> conan, reading
  311. <mfusco> conan, yes I pointed dzonca to docs
  312. <conan> mfusco  prova created this snd/rvc model
  313. <kie-jenkins-bot> Project droolsjbpm-integration build #760: UNSTABLE in 1 hr 48 min:
  314. <conan> so prova could be an Actor
  315. <mfusco> yep, that's very similar to the actor model indeed
  316. <conan> so it's how prova could be wired up to akka or equivaent
  317. <conan> mfusco
  318. <conan> it's all htere
  319. <jbossbot> Title: Reactive messaging - Reactive messaging - Prova Rule Language
  320. <conan> they did good research
  321. <mfusco> k
  322. * mdessi has quit (Quit: Leaving)
  323. * mdessi ( has joined
  324. * mwinkler has quit (Quit: Leaving)
  325. <kie-jenkins-bot> Project droolsjbpm-integration-7.7.x build #49: STILL UNSTABLE in 1 hr 38 min:
  326. <kie-jenkins-bot> noreply: JBPM-7190: filter parameter is not a required param in Swagger
  327. <jbossbot> jira [JBPM-7190] Filter parameter in RuntimeDataResource.getProcessesByFilter is not required [Resolved (Done) Bug, Major, KieServer, Maciej Swiderski]
  328. * tzimanyi has quit (Quit: Bye)
  329. * dgutierr_ is now known as dgutierr
  330. * mhussain (~mhussain@ has joined
  331. * cchianel is now known as cchianel|lunch
  332. <volothamp> mfusco:
  333. * jpetrlik has quit (Quit: Leaving.)
  334. <conan> mfusco
  335. <jbossbot> Title: Guards in message processing - Reactive messaging - Prova Rule Language
  336. * omolinab has quit (Quit: Leaving)
  337. * lterifaj has quit (Quit: Leaving)
  338. <conan> mfusco
  339. <conan> see 1.8 guards in prova
  340. <conan> mfusco  again the key to understanding prova, is understanding prolog.
  341. <mfusco> conan, thanks
  342. <conan> and that the LHS can be far more powerful than we have with pure production rules.
  343. <conan> you can end up with more tight and succint solutions
  344. <conan> that trying to do everything through consequences
  345. * conan_ (~conan@ has joined
  346. <conan_> mfusco  got disconnected
  347. <conan_> [16:33:07]  <conan> and that the LHS can be far more powerful than we have with pure production rules.
  348. <conan_> [16:33:17]  <conan> you can end up with more tight and succint solutions
  349. <conan_> [16:33:24]  <conan> that trying to do everything through consequences
  350. <conan_> [16:34:19]  <conan> mfusco it's hard to explain. but it's why I've said you thnk of the LHS as acutally more like a stateful and incremetnal "functinoal construct' as in functional programming.
  351. <conan_> [16:34:25]  <conan> i.e. the LHS can be more like a utility
  352. <conan_> [16:34:26] Disconnected
  353. <conan_> [16:34:30]  <conan> than a business rule
  354. <conan_> ---
  355. * conan has quit (Read error: Connection reset by peer)
  356. <conan_> just in case
  357. <conan_> mfusco  of partcular interest in the docs, as well. are timers and reaction groups.
  358. <conan_> "This example is somewhat contrived as there are better ways to achieve the same result using reaction groups. Here is a solution from hohpe_using_groups.prova. The sorted accumulator collects all offers sorted by the offer values. If the @size(1) annotation was not added to the exit reaction @or, the outputs would have continued every second. The @size(1) output just one collection with the results and the exit reaction extracts that first result and
  359. <conan_>  prints the highest offer."
  360. <mfusco> conan_, reading
  361. <conan_> take a look at teh sample
  362. <conan_> it's pretty cool
  363. <mfusco> ok
  364. <conan_> they are collecting all bids, over 1sec period.
  365. <conan_> because of the way our system works
  366. <conan_> everything has to go in ksession.insert
  367. <conan_> or named entry-inserts
  368. <conan_> and an entyr-point per node, would be rediculously heavy
  369. <conan_> also bear in mind that the rcv has no "delete" so it has to be opimised for stream inputs (something else we discussed before). to optimise our network for streams (once we have marshalling fixed).
  370. <conan_> mfusco righht now we only support timers as a declartion on a rule. but actually the timernode can be at any point in the network.
  371. <conan_> mfusco  futher notice how prova is instantiating stuff on the LHS
  372. <conan_> even doing printoutst
  373. <conan_> Acc = ws.prova.eventing.SortedAccumulator(), @group(bids) @timer('1 sec','1 sec',Acc) rcvMsg(XID,self,Me,respond,[Service,Offer]), Acc.processAt(Offer,Service),
  374. <conan_> println(["Received offer: ",Offer," from ",Service]).
  375. <conan_> we can do the same, it's basically our "eval".
  376. <conan_> there is no reaoson why you cannot do a printout in an eval (mid network).
  377. <mfusco> yes, not really readable though
  378. <conan_> it's just a different style
  379. <conan_> prolog people wuold say it's far superior :)
  380. <conan_> mfusco  alos see 1.10. Workflows and business processes
  381. <conan_> now that fascinates me
  382. * jlocker has quit (Quit: Leaving.)
  383. <conan_> showing extensions to allow you to model BPM llogic in ruels
  384. * egonzale has quit (Ping timeout: 240 seconds)
  385. <conan_> if we tried to do that with production rules. while possible, it would get really verbose.
  386. <conan_> and wasteful, due to the ksession.inserts
  387. <evacchi> conan_: that example kind of sold the approach to me
  388. <conan_> I'm not saying its not without problems
  389. <evacchi> I'm not convinced about their use of annotations though
  390. <conan_> but I think it's interesting
  391. <conan_> yeah
  392. <evacchi> I mean, it's weird how it fits in the prolog model
  393. <conan_> but we need the foundations in
  394. <conan_> so we can tinker with these things
  395. * sr_pere__ ( has joined
  396. <conan_> I need to expand mfusco's mind
  397. <conan_> so we can explore, and see what works and what doesn't.
  398. <conan_> half the battle, is getting people to think beyond simple business production rules
  399. <conan_> evacchi  but now that mfusco gets the snd/rvc
  400. <conan_> we have progress :)
  401. <conan_> small victories
  402. <mfusco> ok :)
  403. <conan_> typically once those things are in place
  404. <conan_> you can build on those abstractions, explore them, get greater understandings.
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand