Lars Pind on Jan 30 2004 11:33:35--
> The toolkit features of OpenACS are very important, because
> it lets us efficiently build applications and features that
> attract users, and it makes OpenACS perfect for slapping a
> good web UI on top of older back-end systems (systems
>integration above), I do not see toolkit as a goal in itself.
In principle, I agree with this, but I do want to emphasise the importance of OpenACS as a toolkit. As you said, we're not sexy enough to attract developers to the toolkit itself, but I think that once those developers come and begin to discover the inner workings of openacs, they must find that as a toolkit we are as good as anybody out there. I think that in many ways, we are already better than most.
I think that along with the roadmap outlined in this thread, we need to embark on an "API cleanup" of sorts. Much of this cleanup work has already been done, but it's time to take it one step further. There are a lot of deprecated procs around that have been carried through multiple versions now. There are also some procs that have been replaced with new procs, but little indication is made which of the procs the developer is supposed to use. The API should be modified, where needed, to provide a clear and consistent interface to core functionality. API's should also make liberal use of namespaces, and tcl interfaces should be provided wherever possible.
There is also much that was written to work around the limitations of tcl 7.x, where now we have the ability to write much better code with 8.x constructs. Code that is obviously guilty of this should be rewritten, preserving backward compatibility whenever possible (multirows are a good example of something that could be reworked). Use of upvar and uplevel should also be examined to ensure we aren't making things hard for the developer when they have to read our source.
Documentation is probably better now than it has ever been in any *ACS project, but again I think we can do better. Much of the design docs are original aD, and not necessarily relevant anymore. A "Developers Guide" has been somewhat elusive because the recommended best practices and much of the API has been in a state of flux. I think the API cleanup would go a long way toward making such a document possible.
I don't pretend to think that what I've said is anything new, but I do think we've reached a point where OpenACS needs to have more community support holding it up, or it's liable to collapse under it's own weight. I think improving the toolkit portion of openACS is critical to building the needed developer community. Not only does the barrier for users need to be lower, but the learning curve for developers needs to be eased as well.
OpenACS is a project with rough edges, but it still holds a lot of potential, which is why this "silent complainer" wants to help make it the best.
