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

Hi everybody,

Right now, I just want to tell everybody to calm down. Let's not turn this topic into a flame. Everybody on this community loves OpenACS, we don't have to convince each other; that's what this topic is about in the first place. I guess Frank doesn't want to convince everybody to stop their work and to go on a different directio. We are just having a good and mature discussion about the future possibilites, and in my point of view these discussions should happen more times. This is how the technology evolves.

Considering this, I would like to make some comments on Frank's ideas:


- An open and mature programming language understood by a maximum number of developers (i.e. PHP, Java, Python, Ruby, probably in this order)

As much as I like Tcl, I guess you're right about this somehow. Every time we need to hire someone is very difficult to find a newbie who knows Tcl. But as we are considering business environments, I guess this is not the most important issue. Take a look at SAP, for example: they have their own proprietary language and there's a lot of people who knows it. It's because the market have a good financial compensation for people who know it. In Brasil, we have a strange phenomenon: we need Cobol programers. Yes, Cobol programers get very well paid.

Languages come and go from times to times, and if people get paid to learn one of them, they will know. But in order for this to happen, we need enough market share, and that's not certainly the case for OpenACS.


- Open, mature and popular Web, application and database servers (i.e. Apache + PostgreSQL/Oracle).

I guess you got the point here. This is the worst problem in my point of view. You see, OpenACS is the best tool until now for corporative environments, but big corporations have IT policies for applications and infrastructure. Almost all the companies that I know don't have AOLServer in their corporative policy, wich basically means that you can't host an OpenACS based system on these environments.

The best approach to solve this problem is to create some intermediate layer in the way we can still program in Tcl, use AOLServer commands (ns_*) and the service runs easily under Apache, for example. It would be mostly like the JBoss + Tomcat approach. If we can do that, corporations would adopt it easily.


- A migration path from OpenACS to the new system. Pound could switch between the systems based on the URL, if the two system would work against the same OpenACS data-model.

I don't like the "migration" word. Maybe we should have some technology that allowed both system to coexist: some new OpenACS, on whatever technology, and old OpenACS, the same way it is designed today. No migration stress.

Your other comments are more related to implementations, and I guess we can do it even inside OpenACS. It's just a matter of time and effort to make it happen, and I agree with most of them.

As a final comment, maybe it's time to evaluate all the "migration out" tries until now and study where they've failed, so we can choose a common path.

Thanks for the comments and best regards.