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

Request notifications

Hi,

Does anybody have a copy of the "nice JSP version of ACS 3.4" code that Philip referred to in the URL below?
- http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=000tcP

Cheers!
Frank

Hey Frank,

It took me a long time in search, but the best I could find is this: http://www.redhat.com/docs/manuals/waf/

It seems like when Red Hat bought Ars Digita they kept selling ACS as Red Hat Web Application Framework, pretty much a Java Version of OpenACS, with the same datamodel.

I couldn't find code or anything, cause it seems to be a paid issue. Maybe you are lucky.

Frank, I'm curious, why do you want such a thing in the first place?

Eduardo, I'm pretty sure that WAF thing from Red Hat is not what Frank is looking for.

By c. mid 2001 at ArsDigita, there had been two Java-based versions of the ACS. The first one was essentially a direct port of the Tcl parts of ACS 3.4 to JSP. A small team did that, probably led by Jin Choi. That's what Philip and Frank are talking about. It was said to work just fine, but I don't think it was ever used on a real project. Being JSP rather than J2EE, it was believed (not sure by who; presumably management and/or the "core team") to be "not Java enough". (I don't know if that was real feedback from a real person, or just the imputed views of the coveted Fortune 500 customers.)

Thus, that JSP version was quickly discarded in favor of work on a new J2EE-based ACS. That version of ACS Java was, I believe, based on the then-new ACS 4.0 or 4.2 data model, with shiny new J2EE stuff on top; Tomcat servlets, XSLT, and I don't know what else. It also included lots of other very complicated sounding brand-new stuff, like an object-relational mapping layer. That J2EE-based ACS was used on at least one large client project, Deutsche Post, and probably some others. The limited feedback I heard on that toolkit was pretty negative... but that's the beast that lived on at Red Hat and presumably eventually evolved into WAF.

That was all a long time ago now and I had no direct involvement with any of the Java stuff, being busy with my own unrelated projects. If for some reason it's important to nail down though, there are bunches of ex-aD folk out there who actually worked on or with one or more of the ACS Java toolkits, and could no doubt give a more complete answer.

Hi Eduardo,

I've got the following URL from a contact at RedHat. WAF is part of this "APLAWS" application:
http://sourceforge.net/projects/aplaws/. The code is open-source.

Hi Andrew,

Thanks for your explanations about the JSP and J2EE versions.

The reason I'm checking now is that one customer recently canceled the 2nd phase of a large project because of AOLserver and TCL. He compared this technology base with a "piece of shit sticking out of the anus of an expensive Japanese goldfish". Also, it's always good to think about a plan B in case Dossy stops maintaining AOLserver...

Also, some people have asked me: "If you could start to develop ]project-open[ from scratch again, what technology would you use?"

I think, I'd probably use Java for a number of reasons and keep the existing data-model with very few changes. So this is why I'm looking for existing code. But I think I'd use neither plain JSPs nor J2EE. Instead, I'd develop a new framework from scratch consisting of building blocks inspired by FormBuilder, ListBuilder and the ]po[ Portlet and Menu GUI elements. This framework would be based on plain SQL statements for ListBuilder and on a SQL metadata system (AMS/ ]po[ DynFields/ Quest FlexBase) for FormBuilder, instead of the usual Java business objects and a persistence mapper. Google Web Toolkit (GWT) seems an interesting option for low-level GUI widgets.

Cheers!
Frank

Collapse
Posted by Frank Bergmann on
Hi,

Here is a pretty good documentation about WAF:

http://www.opendocs.net/redhat/waf/rhea-dg-waf-en-6.0/

Cheers!
Frank

Collapse
Posted by Eduardo Santos on
Hey Frank,

I did the same contact with Red Hat some years ago, and it seems like you've got better luck. I didn't know this aplaws thing.

As most as I like OpenACS, I have to agree that we should look for a better technology solution. And the biggest problem for acceptance is AOLServer.

I also don't know if I would use Java, but as they already have something very similar to OpenACS (I didn't check it for compatibility yet) I would choose it for less effort.

Maybe I'll take a deeper look at it sometime.

Why would a company choose to have a portion of its income depend on a client that does not make rational decisions?

If AOLserver is not considered well maintained due to low change activity, then consider Naviserver.

What happened to the proprietor of ACS when it moved away from the core technology that spurred its growth?

(rhetorical questions)

best wishes,

Torben

Hi,

Thanks for the opinion. I guess we all have our personal favourites. Mine is Prolog, which is actually quite related to Erlang. Checkout http://www.fraber.de/sitec/ :-)

But I believe we'd have to apply different criteria if we want to put together a large and successful open-source community again. Brian Fenton and I had a nice conversation last night about this subject. Obviously, we also need to consider Quest AIMS and ]project-open[ for this.

We'd basically need:

- An open and mature programming language understood by a maximum number of developers (i.e. PHP, Java, Python, Ruby, probably in this order)
- Open, mature and popular Web, application and database servers (i.e. Apache + PostgreSQL/Oracle).
- 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.

Then Brian asked a great question: "What is today's equivalent of Phil's ideas then? ACS was revolutionary in 1999, what would be the equivalent today?"

My best take on this mega-question is to list the applications that currently "inspire" me:

- OpenACS: Great collaboration and high performance.
- Thingamy (http://30megs.com/, http://thingamy.com): Allows you to rapidly build small applications.
- Microsoft Access: Like Thingamy, it allows beginners to quickly build small (and not that small...) business applications.
- Microft Sharepoint: The AJAX tables are just great. Apart from that it's basically a kind of OpenACS.
- Google Wave: The ultimate, unified collaboration environment.
- Oracle Forms (http://cisnet.baruch.cuny.edu/holowczak/oracle/dev2k/9ids/): The base of the Oracle ERP system.
- SalesForce: Large community, incredibly successfull
- SugarCRM: Incredibly successfull.
- Basecamp: Incredibly successfull.

Other requirements are:

- Multi-platform (Linux, Win, ...). Needs to install on Windows without hassle.
- GUI is optimized for mobile devices
- Mesh-up with Web services

Both AIMS and ]project-open[ rely on a number of features that should go right into the core of such a system:

- Dynamic workflows from acs-workflow, but with a cool workflow edior like Thingamy or Oryx
- Dynamic object extensions á là AMS, AIMS Flexbase and ]po[ Dynfields, integrated into all GUI elements

In terms of architecture I's stick with the OpenACS style of "the objects live in the database, not in the memory" and "coarse grain GUI components":

- A kind of ListBuilder, but integrated with an AJAX GUI like Sharepoint and FlexBase/DynField meta-data for in-cell editing of object fields.
- A kind of FormBuilder, but with a graphical form editor like Oracle Forms that draws on FlexBase/DynField
- A dynamic GUI similar to the one in ]po[ with permissions for menu tabs and portlets.
- A package manager similar to OpenACS
- A GUI based on YUI or GWT.

Admittedly I'm taking a focus more on business applications then on Web site building. Also, as Brian just rightly commented, I've been missing the last two years or so of developments in the R&R and Python worlds.

Cheers!
Frank

http://www.project-open.org/
http://www.project-open.com/

Collapse
Posted by Jim Lynch on
We'd basically need:
  • An open and mature programming language

Just a second... Are you asking the entire community to abandon and replace a technology that's been working since 1995 or thereabouts and well tested the whole time because some guy compared the platform to a turd outside a fish? We're now going to jump on the bandwagen of java or php because it's more marketable? You do understand that judgements like these have been around for years (many of them boil down to school rivalry) during which openacs continues to work just fine?

Bullshit. That's right, I call bullshit.

At least be honest and say that you lost the sale and possibly the customer because the marketing failed, not because the product failed.


At least be honest and say that you lost the sale and possibly the customer because the marketing failed, not because the product failed.

Yet the marketing may have failed because the product was perceived to be lacking in some way.

Maybe it's worth discussing how to market OpenACS effectively. We all know it's a great framework -- but the obscurity of the platform may be turning away developers and clients. What have people done to overcome this?

Collapse
Posted by Nathan Lunt on
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.

Frank, why do you particularly care "to put together a large and successful open-source community", and why do you think that using PHP, or some other "programming language understood by a maximum number of developers", would be the or a good way to do that?

Note, what little empirical research I've seen on how software tools become popular doesn't seem to suggest that using PHP rather than Tcl is likely to be that significant. Indeed, my understanding is that Tcl's first and strongest wave of popularity was directly because Tcl/Tk did GUIs far better than anything that had come before. (I haven't read my copy yet, but Stanley Lieberson's A Matter of Taste: How Names, Fashions, and Culture Change may also be relevant here.)

And anyway, the great thing about ACS and OpenACS when they first arrived on the scene was that they solved web development problems better than anything else out there. That's what I care about, that they're useful tools. If I wanted to build a next-generation web development toolkit, I'd think hard about three things: What new problems I want to solve; if any other tools or techniques out there might help me solve them better; and how to carry forward all that was useful and important about my old problem-solving tools.

Now, from that rest of your post, that stuff you've already been thinking about, very good. But...

IMO, a large community is principally a side effect, not the goal.

If you want a suite of generic but popular web tools, why not just go use them? If the goal is popularity of something similar to OpenACS, well, I'd probably pick an already-popular toolkit and figure out how to both enhance it to take advantage of what I learned from OpenACS, and convince the rest of its community to adopt my changes.

If you want new and better features like those you listed above integrated into your web development toolkit, well, seems the main questions to answer are "how" and "added to which base toolkit?" In other words, enhance OpenACS to do what you want, or enhance something else to do what OpenACS does?

Those are important and interesting questions, and I'm definitely curious what answers you ultimately come up with! (Please do let us know.) But I think that so far your, "and I also want it to be popular, how do I do that?" question is poorly posed; it doesn't mesh with the rest.

Also, the Clojure folks seem to be innovative; it's not just Yet Another Implementation of Lisp on Java, they're also trying programming language ideas that are probably of some interest even if you care neither about Java nor Lisp. Yet they run on the JVM. So, you may want to talk to them, see to what degree that Java integration seems to be helping them with popularity, acceptance at large companies and other big boring institutions, etc.

Collapse
Posted by Andrew Piskorski on
If I was going to build something like either OpenACS or a complex OpenACS-based application from scratch, I certainly would not choose to use Java for it. Gah. Although if for some reason I really needed to operate in a Java-centric world, I'd look into Rich Hickey's Clojure.

I'd say OpenACS, AOLserver, and Tcl have held up pretty well over time. I've been very pleased with how well Tcl works with AOLserver, and in particular with how productive a programming environment multi-threaded Tcl is. (Not perfect certainly, but much, much better than most.) And, PostgreSQL and Oracle and were and still are obviously good choices for the RDBMS.

However, there are certainly some interesting and potentially very powerful tools out there now which simply weren't available back when OpenACS got its start.

The number one tool I'd seriously investigate is Erlang, its OTP libraries, and associated ecosystem. From what I've read over the last 7 years or so, Erlang is probably the best environment available for doing (asynchronous, pattern matched) message-passing, massively parallel shared-nothing concurrency, failure recovery, live code update, and high reliability.

The only programming language I know of that may well be better for embedding than Tcl is Lua. Lua's community also has some very interesting technology, particularly Mike Pall's LuaJIT 2.0. If I needed simple, lightweight, high-level, fast programming language, I'd strongly consider it.

There is currently lots of activity - seemingly dozens of startups - in massively-parallel shared nothing RDBMSs. Nothing yet really open source though, and AFAIK the commercial systems (Teradata, etc.) tend to be very expensive. So these databases definitely bear watching, but don't seem like a practical approach for a general purpose web toolkit yet. I'd stick with PostgreSQL (and Oracle).

The opposite end of the database spectrum is also interesting, namely very small and simple databases like SQLite. D. Richard Hipp has himself done some interesting work on using SQLite to build a self-contained, SourceForge-equivalent website which installs trivially and runs from one of the lowest-cost hosting providers like Hurricane Electric. That sort of tightly focused DB-backed website design is interesting, and might actually make for a better product if you're selling the software, but may be less applicable to a general purpose, more sprawling toolkit like OpenACS.

Oh, and from the limited info available, Dave Fayram's Katamari, (which is based on his older fuzed project sounds like an interesting tool for managing and scaling a bunch of websites or services written in N different programming languages. I personally wonder to what extent it would also naturally extend to operating as a more flexible cluster job scheduler/manager, in place of Sun Grid Engine, SLURM, or the like.

Notice that above I've basically just listed various nifty new programming languages, tools, and applications which, if you were starting today, might be very helpful in designing and building an OpenACS-class toolkit for complex interactive web sites and services. That's because those are the main areas I see where new stuff is likely to be a significant win. AFAICT, the basic data models and design of OpenACS are still quite sound, and I'd likely adopt them more or less wholesale.

Of course, there probably are at least vaguely OpenACS-like systems out there using some of these tools. Obviously there are smart people out there doing dynamic websites with Erlang, Ruby, etc. etc.; not everyone is using PHP and MySQL, nor Java J2EE. Others here are probably familiar with some of those communities' approaches and solutions.

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.

Frank: take a look at acs-object-management in HEAD for another object management system (in addition to Flexbase).