Forum OpenACS Development: Re: "Nice JSP version of ACS 3.4" - Does somebody keep a copy?

Reasons this platform switch and rewrite is a bad idea and not well thought out:

  • TCL is open and much more mature than any of PHP, Java, Python and Ruby. If your developers can't pick up a language as easy as TCL, then you have a problem that is unlikely to be solved in this forum.
  • Using AOLserver gives us all the performance benefits that everyone is trying to get with various caching modules for PHP and other platforms. Switching to PHP (or anything else) + Apache just means we have to implement a middle layer for function caching that we already have working perfectly. Not implementing the equivalent of in memory procs means we no longer have the performance benefits.
  • We can't even do sane migrations between point releases in real world environments that contain significant customizations. There is no way any smart company in the business of customizing OpenACS is going to buy into this, so if the platform changes, everyone will stagnate and blame this guy who thought it was a great idea to just change everything.
  • OpenACS has the ability to get to the point where all the CMS platforms listed are. It just comes down to having the resources to build the widgets and marketing. If you can't figure out why we haven't done all this with the existing code base, how do you think we'd ever get it done starting from scratch? For what it's worth, progress is ongoing for integrating YUI in a sane way, but that work will be for naught if we switch to the latest fad language.
  • We many years and thousands, maybe millions, of lines of stable, well-tested code. There is nothing wise about leaving that behind.
  • If ArsDigita and Redhat with all their resources couldn't make a Java ACS fly, why would we begin to think we can do it with the minimal resources available to us now?


If you want to build a new platform based on the ideals of OpenACS, fine, but to think it could replace the existing platform is absurd.
Hi!

Although I'm getting late to this interesting thread and I think this have been discussed some time ago, some comments of my own experience (I'm not a full time developer).

I'm totally agree with Nathan and all opinions regards to why change a solid path to a not-sure success one. I think:

- Aolserver Rocks. I'dont need Apache. As much as I work with AOS I realize that it rocks
- TcL rocks. With 30 hours of learning you can . Yeah! It's old but it's amazing and the API with Aolserver works great. Also, it has very good documentation.
- OpenACS is bit, very mature and the only problema I see is that it's too much code (needs some polisshing) and complex (better and polish documentation).
- I did not make same mistakes again (Change ACS technology and then realize we already had that tools). We need to focus in not-so-techical stuff, perhaps that's the problem

I don't think that the problem is the technology. I understand business needs but, come on, think about selection developers based on knowledge on X o Y technology has been proved as a bad strategy. It's the guy not the tecnhology what's important.

To think about future I suggest:
- Polishing, Polishing, Polising. Work with code is a lot of times hard, we need to improve access to available code (our problem is not lacking functionality but finding than functionality in existing code)
- Improve Documentation and Marketing: too costly to access first working site and begin to develop. But new effort are improving.

I'm not as experienced as everybody here are but I only need better accese (in an easy, quick and right approach) to existing code.