Forum OpenACS Development: Re: How to do sessions

9: Re: How to do sessions (response to 1)
Posted by Andrew Piskorski on
Sal, if you can't understand how the current OpenACS user login and registration code works by reading and playing with it, then I have no idea how the hell you hope to write something better on your own. The current OpenACS code might not be a model of simplicity and clarity, but neither is it all that complicated. If you're actually good enough to write your own, you're more than good enough to read the OpenACS source, understand it, and figure out how to modify it to suit yourself.

I would go with the latter approach. Also, if for some reason I needed to write my own user tracking code complete with users table, etc. (e.g., for an entirely different system), I would certainly read the OpenACS code, make sure I understand why it's doing things, and then use it as a model.

10: Re: How to do sessions (response to 9)
Posted by sal berg on
I think you are right, Andrew. Despite having done software engineering for major companies such as IBM and others, I can't understand most anything about OpenACS. Oh, in truth, it isn't that I couldn't sit down and reverse engineer the system and understand it, given enough time and energy. It's that most sane people wouldn't want to put forth the effort to sit down and do that.

So you are right - I'm outta here. This is the last post I will bother you people with.

11: Re: How to do sessions (response to 10)
Posted by Andrew Piskorski on
Sal, that's ironic, as my personal experience is that the OpenACS codebase, particularly the Tcl layer, is fairly easy to modify. Are you sure you're not just hitting the old, "starting over from scratch seems like it would be more fun" programmer's bias?

I've many times had that "this is junk" feeling when staring at a big pile of foreign code that I wanted to make do something new, but more often than not, as I learned how it actually worked, I realized it wasn't junk at all. Modifying and refactoring old known-working code never sounds as much fun as writing something new "from scratch", but it's usually the more effective approach. (You're unlikely to really understand the problem until you've worked with the old code.) This is only more true when the existing code is both battle tested and friendly to modification, like OpenACS.

Taking a rather large toolkit like OpenACS, and then deciding to write your own users table from scratch, is, as anything other than an academic or tutorial exercise, a pretty strange approach. OpenACS's single biggest strength is arguably its well thought-out data model, so totally ignoring a core part of it like the users table makes no sense.

You'd probably have been better off explaining what custom behavior you want your site's "login and registration system" to have, and how you're having trouble using OpenACS to do it. Since you didn't tell anyone what your actual goal is, you're a lot less likely to get the advice that would be most effective in solving your problem.