Forum OpenACS Q&A: Response to Request for Comments and Discussion: Building a Leaner, Meaner OpenACS with MIST

Collapse
41: Response to Request for Comments and Discussion: Building a Leaner, Meaner OpenACS with MIST (response to 1)
Posted by Ben Adida on 10/04/02 10:52 PM
A few more answers:
  • Dan: you're implying that if I say anything negative about OpenACS, I'm insulting Don. Should I just shut up unless I have good things to say, then? I see certain issues, and I try to propose solutions that we can all discuss. There is nothing disingenuous in what I'm saying. I am not blaming Don. If anyone thinks I'm blaming Don, they are wrong. I didn't blame him in my paper and I'm not blaming him now. I simply think we all have made a mistake in delaying something like MIST. I'm looking for rational discussion around that idea.

  • Dan, again: I think the core was already too big when aD released it. And in fact, I seem to remember that we all agreed on that. We recommend using acs-mail-lite instead of acs_mail whenever possible. We agree that acs-messaging should probably be dumped. We agree that acs-workflow should not be installed as part of the core. Some don't want content repository installed by default, either. So let's do something about it. It wasn't right 2 years ago, and our lack of action doesn't make it any more right today.

  • Don: agreed that we can shrink the toolkit size without MIST. That's an excellent point. Now, I'm not so much pitching a new way of breaking things up, I'm pitching a new way of putting them back together for users. If it's easy to put things back together, it's an easier decision to make to break things up.

  • Jeff: great comments and great analysis, thanks. I initially thought about an XML-driven MIST, but then I realized that the installation itself might be a bit more functionally-oriented than data-driven. But certainly nothing is set in stone, this is just a proposal. Understood about the documentation complaint. We're trying to fix this first by doing the new-portal cleanup with documentation in parallel.

  • To clarify, the source code for new-portal is available to Janine, who manages both dotLRN and OpenACS, and she can make any decision she wants on what tarballs to include it in: the code is owned by MIT Sloan and managed by the dotLRN boards. OpenForce is only wrapping up cleanup and documentation as a means to help future work in that direction, and will provide that code ASAP to Janine for inclusion in whatever version of OpenACS and/or dotLRN she sees fit.

  • Jeff, again: OF is definitely willing to contribute resources to build MIST, sorry I didn't make that clearer. That's why we're making the proposal, to see who would find this useful before we put time into it. No client is paying for this. This is definitely not a request that current volunteers shift their focus to MIST. This is what I'm interested in and I thought it might be useful to more than just me, that's all.

  • Simon: on the contrary, MIST is meant as an end-user tool to enable end-user configurations. Developers would use MIST only when it comes time to package a distribution of the stuff they've written.