Forum OpenACS Development: Response to Gratuitous use of acs_objects?

Collapse
Posted by Lars Pind on
To Jon: Yes, I was the one who designed this system along with Michael Yoon, so I know all the reasons for including both Party and Person. It just isn't worth the performance and other penalties in practice. You can have a separate persons table, and when someone registers, you just copy over the info from one table to the other, without penalizing operations on Users, which are so much more frequent.

We should absolutely,positively, allow for a screen name/user name instead of email, as the unique user identification method.

To Don: You're right. This only reduces the number of tables and joins.

I haven't looked this through in detail, either. All I have is a strong desire to find ways to make it more lightweight, both in performance, learning curve, and effort to develop with it. I'm trying to figure out to what degree we need a radical or an incremental approach.

I've also thought of the possibility of a more "interface"-based approach. The idea is that, when two object types (say, persons, and users) share some common attributes (say, email), instead of creating a table to hold the common attribute column, you could have the same column in both tables, and have a way of saying "they're really the same attribute", like you do with interfaces in OO languages. That way you can reduce joins. Don't know how useful that'd be in practice, but it's a thought.

Stephen: Yes, abstractions, and implementing things in general ways in the core for all applications to use, is very important. But it's also important to allow rapid application development, easy training of new developers, and strong performance.

While I like, in principle, all the cool things you can do with these cool abstraction (and I was part of designing most of them), I think there are significant costs along the three dimensions mentioned above: 1) time to learn, 2) time to develop with, 3) performance.

I believe we went overboard then, and we need to back off a bit. Parallels abound ... SGML to XML, X.500 to LDAP (L is for Light-weight). I've come to see the value of fewer and simpler abstractions, which, admittedly, is a worse model of reality in some respects, but it's workable, and it saves a lot of overhead.

I guess I should write up something about these thoughts soon.