Forum OpenACS Q&A: Re: Proposal for a web service based rule engine

Collapse
Posted by Nima Mazloumi on
I agree. The problem is, that status changes take place in an external system. I could make it a requirement that OACS is informed via web services about those changes.
Collapse
Posted by Tom Jackson on
"The problem is, that status changes take place in an external system"

That is your basic problem. Essentially you have two or more independent systems, which is not good. Something occurs to me that you might be better off looking at an LDAP database for this type of problem. If you wish to use an external system, maybe use a separate-from-everything-else rule engine. Feed data into it from all sources which determine status and use the rule engine to make the decision, but first you need to get all the rule data into a single database. LDAP is difficult, but I can almost guarantee it is much easier than XML and xpath, and designed to be fast at this kind of task.

Collapse
Posted by Jim Lynch on
Nima Mazloumi on 06/04/07 01:33 AM:

"I agree. The problem is, that status changes take place in an external system. I could make it a requirement that OACS is informed via web services about those changes."

Sure, this is all true... and you could solve the -external- issue. But by "status change" I really just meant the following actions:

  • Adding a user to the system (which would somehow accept info about the user's status and then you set permissions accordingly)
  • user's external state change, where somehow this change is reported to the openacs instance, which responds by altering permissions

with the ultimate result being that:

  • all changes are (somehow) communicated to the -permission system-
  • no additional queries are needed in the openacs code beyond checking the -permission system-, and
  • therefore already-written code will already work for free, because it does check the -permission system- already.

The permission system is very robust, flexible, easy to use, nice api; overall it's great. I'd suggest using it!

Additionally, you will probably want to store the status in a table but only for the purpose of keeping together what could be a -set of- permission settings meant to implement -one- status. That way, it will be easy to undo changes; you can have API that lets you say "Freddie Freeloader's status has changed from Student-in-physics-classnumber-1234 to Teachers-assistant-for-physics-classnumber-1234" causing potentially many revocations and grants on many objects, as well as removals and adds to groups which already have appropriate permissions on appropriate objects.

Collapse
Posted by Nima Mazloumi on
Ok. I got your point. The first point is implemented. The status is checked once and the permissions are set accordingly. The second - reporting status changes back to oacs and altering permissions - is work in progress.

Would you rather pull or push this info? I could either provide a scheduled proc that asks for changes or provide an interface in oacs that is called when changes take place?

Collapse
Posted by Jim Lynch on
Why not table that decision by allowing both at the option of the user?