Forum OpenACS Development: Response to Gratuitous use of acs_objects?

Collapse
Posted by Don Baccus on
something i think would help OACS a lot is better guidelines for application developers as to what to make an acs_object and when/where to use permissions. (note i am not offering myself as the author of these guidelines, i hate writing and am not good at it)
Just by coincidence (really!) John Mileham, at the Berklee School of Music, mentioned in passing that they've developed some ideas about "best practices" there. He contacted me in response to the thread about Sloan/Berklee that's over in the general forum.

Anyway, I asked if he'd have the time to write them up and post them, in order to trigger discussion about community-wide guidelines as to how we'd like to see various bits of core functionality used.

He's interested in writing up at least a sketchy description of their thinking for us to take a look at and to pitch in and help create a doc for the community at large.

I think this would be a very good thing to have. Without putting pressure on John or publicly committing him to a lot of work, I'm hoping he'll have time to put something on paper soon.

Roger Williams is also working up some suggestions for changes to the permissions system that he intends to share "around June 1, maybe". I think he means this year :) He's been working through various discussions we've had about permissions in the past, sifting through them and using them as a basis for his proposals. This should help give focus to further discussions as we try to decide what to do in 4.6.

More generally ... this is a great discussion. Stephen, I don't think we're talking so much about removing functionality as streamlining it. If we can streamline stuff and make core functionality easier to use and prove that it scales well without a bunch of hair-pulling on the part of developers, everyone will use that functionality by reflex. We won't be seeing folks suggesting that maybe bboard posts shouldn't be objects because we'll make using objects as pain-free as we possibly can. At least that's where I'm coming from.

Dan ... in terms of rels I really do like having them be objects so you can build rels on top of rels ... my comment (in case it wasn't clear) was only that the ROWS, as Yon also says, shouldn't be objects. I don't think that costs us any practical functionality and has the potential to remove a LOT of objects from systems that make heavy use of acs_relations.