Forum OpenACS Q&A: Future directions for OpenACS

Posted by Edmund Lian on 02/02/01 08:20 PM

The on-going flamefest on the AOLserver mailing list regarding
certain attitudes towards the Open Source community caught my
attention due to the references to aD moving away from AOLserver,
OpenACS moving to Apache, a coup d'etat at aD, etc. All very
interesting, but it's left me a bit confused.

Is it the general consensus of the OpenACS community that
Apache/mod_aolserver is the way to go? Are we moving away from
AOLserver/Tcl to Apache/Java? What's really going on? I know and love
AOLserver very much, and have learned to tolerate and even appreciate
Tcl, but if this is on a road to nowhere, I'd like to know fast!

2: Response to Future directions for OpenACS (response to 1)

Posted by Don Baccus on 02/02/01 09:45 PM

First of all, my post to Kriston was private, and was a response to
his ongoing disagreement with Jerry. Obviously, I think that Jerry's
on firm ground. I've followed this saga for the last year as he's
tried to get his nvshr and nsunix work incorporated into the code
base. Kriston has treated him (and others) like dirt. I choose to
slip him a quick verbal punch in the nose - in private, though.

He copied my private e-mail to the list - of which I'm not even a
member, BTW - without asking for my permission, apparently to
"embarrass" me.

So far I've gotten six notes that, summed up, say "thank you" and zero
that say anything else. The point that I e-mailed Kriston privately
seems to have been missed, so I'm being thanked for something I never
meant to do, i.e. tweak Kriston in public!

Oh well ...

Now, as far as the future goes:

aD has released a Java-based version of ACS 4. This is only being
supported in the Apache-Tomcat environment. They are still working on
the Tcl version, but it is safe to presume that they'll slowly be
switching towards Java.

How does this impact OpenACS? Hard to say, we're a community, and we
take a community attitude. If the community wants to continue
supporting Tcl ACS 4, and for that matter extending it with additional
modules, it will, right? I suspect quite a few of us will feel that
way. I personally have a Tcl/ACS/Postgres/AOLserver site that is
going to grow indefinitely. I have no reason to go through the agony
of switching to a new environment when the environment I have works so
well.

On the other hand, many people find Java attractive. I would be
amazed if there's no interest in porting new Java versions as they are
released.

My feeling is that we can be a "big tent" project, in the sense that
in our general space we can find room to accept those who might want
to work solely in the Java space, while continuing to accept those who
might want to work in the Tcl space.

The issue won't be direction in the sense of a couple of folks saying
"this is the direction we'll take", the issue will be whether or not
people who care about one direction or another will also be willing or
able to roll up their sleeves, get to work, and make it happen.

Same for supporting other Open Source databases. I'm interested in
the possibility of our supporting IB or SAP DB as time goes on, but
being personally tied into Postgres means that I'm unlikely to
personally sit down and put a lot of personal effort on the port. I'd
hope that the interests of users of one or more of those DBs would
intersect with the interests of the OpenACS project, and that we could
help find resources, help point out SQL "gotchas" involved in porting,
etc in order to make a port an easier task.

Speaking for myself, I view aDs move towards Apache/Tomcat/Java as
being a marketing, not technical move. People working on OpenACS may
or may not care about popularity in the same way that a business
focused on the bottom line does.

How do others feel? Is there a consensus one way or the other? How
do we tell? We've never even met each other in person (mostly) :)

3: Response to Future directions for OpenACS (response to 1)

Posted by Jonathan Ellis on 02/02/01 11:25 PM

Having developed professionally with ColdFusion, for fun with OpenACS/tcl, and working now in Java, I have to scratch my head and wonder why on earth people would want to move from [any scripting language*] to Java for web development purposes. It is just SO much more aggravating, particularly on the JDBC side. I miss set_variables_after_query. :(

* Okay, I can see why you would want to move from to Java if your scripts were in Perl. :)

4: Response to Future directions for OpenACS (response to 1)

Posted by Adam Farkas on 02/03/01 12:25 AM

A quick note as there clearly seems to be a lot of worrying going on. Java is an interesting platform. Apache 2.0 may eventually be an interesting platform. To me, OpenACS/AOLserver is still very much the way to go in terms of solid enterprise-level web development. I remain fully committed to that platform for the foreseeable future, and I know there are enough members of the OpenACS community out there to keep it a very strong platform for quite a while (not to mention legacy customers).

No, I do *not* recommend running mod_aolserver, except for those who cannot fathom doing away with Apache. If they like mod_aolserver/OpenACS, then maybe they can be convinced to see how much faster and better it is on AOLserver.

As for the state of the AOLserver community, it is, IMHO, quite sad. I agree wholeheartedly with the spirit of Don's message to Kriston, and believe that the AOLserver community must be revived ASAP to ensure a solid future for the software.

5: Response to Future directions for OpenACS (response to 1)

Posted by Ben Adida on 02/03/01 12:42 AM

This is funny. The previous comment was from me (Ben Adida), but I was using Adam's machine here in Brussels ahead of the OSDEM talk. The comment above is mine, but Adam wholeheartedly approves :)

6: Response to Future directions for OpenACS (response to 1)

Posted by Stephen . on 02/03/01 12:49 AM

Is mod_aolserver that terrible? I've always thought AOLserver was techically superior, but quite quite frankly my sites don't get the kind of traffic that AOL has to deal with so maybe it doesn't matter. AOLserver is apalingly unreliable on Linux, I'd just like something that works...

7: Response to Future directions for OpenACS (response to 1)

Posted by Roberto Mello on 02/03/01 02:34 AM

I totally agree with the spirit of Don's and Jerry's messages. Plus Ben's and Lamar's message as well. I've worked in and out of OpenACS with these people and I have the greatest respect for them.

Stephen said that AOLserver is "apalingly unreliable on Linux". I've run AOLserver on Linux since its 2.3 days. I have AOLserver processes that go months without any restart (using nsd76). I do not see that unreliability.

Much to the opposite. People always amaze themselves when they see what AOLserver/PostgreSQL/OpenACS/Linux can do with so little resources. For over a year our 85% dynamic site ran on a P133 with 64 Mb of RAM and a cheapo 3 Gb HD. Granted, we only get about 1000 hits/day, but still. (ArsDigita has since graceously donated a screaming fast server to us. Thanks Adam :))

What I'd like to ask everybody is:

- What can we do to revive the AOLserver community? a fork? A separate CVS tree where we can stest stuff and try to keep in synch with AOL?

8: Response to Future directions for OpenACS (response to 1)

Posted by Don Baccus on 02/03/01 04:27 AM

The main thing we can do is to provide a place where people can go for
help and get it without having to deal with a pile of ... sigh, you
know where this is headed.

Anyway, take this "AOLserver's terribly unreliable on Linux" comment.
There are a bunch of us who have great success with it, so I'd like
to hear more. I'd like to see people more experience helping Stephan out.

You can ask on the current feedback-du-jour mechanism that Kriston's
set up, but you're most likely to first be assured that the reason
you're having problems is because you're an idiot. I got one of those
right off the bat when he showed up and I've not been around much since.

That's not really conducive to getting folks to work to ferret out the
causes of their problems so that either a) proper procedures can be
documented for others or b) the bug you thought couldn't possibly
exist, but does, can get fixed.

I'd also like to see development more responsive to the needs of those
of us who run sites with a lighter load than AOL, digital city, etc.
I was forwarded a digest awhile back for my amusement, in which
Kriston was saying things like, oh, you should really have a gigabyte
machine because anything smaller isn't worth worrying about, blah blah
blah. Total insensitivity to someone who was having problems on a
more modest (but still reasonable) machine.

So ... a community that loses two attitudes would increase the
likelihood of AOLserver gaining more acceptance:

1. If you're not Kriston, you're an idiot.
2. If it doesn't affect AOL, it's not worth talking about.

I'm exaggerating - but not by much.

9: Response to Future directions for OpenACS (response to 1)

Posted by Jonathan Ellis on 02/03/01 09:19 AM

Well, to some extent at least you've already succeeded at "providing a place where people can go for help and get it without having to deal with a pile of crap." At least, I've never found the need to go to the aolserver mailing list to find the answer to my questions (thanks, Rob :).

Rather disheartening, though, that AOL would have such an antisocial fellow as community liason, even if unofficially. No wonder Apache has so much more mindshare. 🤔

10: Response to Future directions for OpenACS (response to 1)

Posted by Talli Somekh on 02/03/01 08:53 PM

i am not the hacker over at musea, not am i the sysadmin, so i can't say a whole lot that would sound rational as far as the technical legitimacy of the aolserver vs. apache/tomcat debate.however, as an evangelist/sales person, the debate is extremely important and due to our particular business model, it is vital.

we would like to serve non-profit organizations with OpenACS; not just with community websites but with database applications as well. we want not just use the toolkit, but to expand it as well with NPO- specific software. we're looking to leverage OpenACS not just as a free toolkit but as a real open source system.

but we don't expect that every organization that could use the system can afford to pay us or others for installation and administration. so we'd like to build a community of volunteer sysadmins that might host an org's system on a kitchen table server or something analogous to that.

since for every one person that has heard of AOLserver there seems to be a million pretty familiar with Apache, we're leaning to developing our OpenACS contributions with Apache as the preferred server. in fact, we're even excited about the port to IIS since so many orgs already have the darkside's systems running and are hesitant to abandon legacy apps.

so we're not totally agnostic to the coming server war - i mean - debate. we don't expect to be building systems that demand tolerance up to 28,000 hits/sec. (if we did have to build such a system i would expect it would provide so much revenue i would volunteer to crawl into their server and serve pages myself.) so apache would do just fine for our needs.

however, i'm worrying myself that by preferring a platform other than that of the community's mainstream, problems will arise concering the continuity of the toolkit. i'm an advocate of not fixing what's broke, especially if it's a waste of resources. in other words, i think doing a port to perl, python and even java would be a waste of time if it distracts from improving and building upon what already exists.

which brings me to what i'm afraid is getting lost a bit and what i think _is_ the future: OpenACS 4.X. Don already admitted this morning that the effort is behind schedule. (which, btw, is an example of why i think this community is so strong. people here are extremely competent, but more importantly people are honest and treat one another with respect.)

but to be honest, we've been in the starting blocks waiting for the gun to fire for a while now. nobody deserves blame for that, of course, because we were at the mercy of aD, PG7.1 and enough open time for Don, Ben and everyone else to sit and start. but now that there has been a commitment to doing it and there seems to be many, many people eager to help i'd like to see a bit more transparency or organization, i.e. something like what aD did on acs40.arsdigita.com.

as far as forking the OpenACS to include alternative languages or platforms, i think it would be a real waste of the community hours. so far we've been kinda beholden to aD as far as new developments on these fronts, but is that so bad? they are getting paid to do that stuff, and they haven't _totally_ screwed up yet.;)

hope things are going well with everybody.

talli

11: Response to Future directions for OpenACS (response to 1)

Posted by Timothy Griffin on 02/04/01 01:58 AM

There seems to be general agreement on the following:

1) AOL's openness to accepting patches does not meet the community's needs as a centralized repository for an "open-source" project. Frustration has reached critical levels.

2) A full fork is a cumbersome and unrewarding activity (though there seems to be sufficient interest within the community to at least consider this option)

How about this for an alternative... aD already maintains and distributes a patch series to AOLserver containing numerous useful additions. Could one or two AOLserver-experts within OpenACS perhaps assist in the effort of maintaining aD's patch series (filtering submissions etc.) and thereby integrate some of the patches (e.g., decent virtual hosting) which aren't a priority for AOL or aD. I'm guessing that aD will be more open to community contributions.

12: Response to Future directions for OpenACS (response to 1)

Posted by Michael Feldstein on 02/05/01 04:55 AM

OK, I'm not a programmer, so my perspective is a bit different. I have to make recommendations to clients about how to solve their problems. Now, I don't really care if the solution is written in Java, tcl, or Logo. I just want to know that what I'm recommending (a) will work, (b) will continue to work, and (c) will not take so many resources to make/keep it working that we lose sight of the business problem we're trying to solve. So far, I've never heard anyone say that a Java version of the ACS will be more reliable, more scalable, easier to maintain, easier to interface with a database, or easier to customize. Quite the opposite. (I have to go by what people tell me since I don't have the expertise to judge for myself). The only thing I've heard on technical merits is that a Java version might be faster.

On the other hand, what I do hear a lot is that clients have a much easier time finding good Java programmers and that they have a comfort level with Java. It doesn't really matter how easy tcl is to learn; that's just not the way most of these organizations work. Furthermore, it sounds like it will take a very serious organizational effort to jumpstart AOLServer development. I'm not talking about patches and life support; unless there is a real, committed development team that will keep the platform moving forward--beyond just point releases--it seems to me that AOLServer will die as a platform that is useful to a community beyond AOL. It may take a long time to die, but die it will.

So it seems to me that there are a couple logical steps for the community to take. (Note that I'm incapable of "rolling up my sleeves," as Don put it, so you ought to consider that as you weigh my vote against those of people who can actually do the programming.) In the short term, AOLServer is clearly still the way to go. I don't see even aD saying that they're ready to build sites on ACS Java just yet. So there's no reason not to press ahead and do what can be done to brighten the future of the platform. Perhaps a new steward can be found--maybe one of the Linux distro makers or some other major Open Source player can be convinced to take it on. I don't know.

Long-term, though, I think the community has to take a hard look at where ACS Java goes. Hey, for some purposes, ACS 4.x tcl (or 3.x tcl, for that matter) will always be fine. That's certainly the case for legacy sites. But I have a feeling that more client money will eventually flow toward evolving ACS Java than ACS Tcl--not because aD will choose to do it that way, but because clients will ask for it. We'll have to wait and see.

It's a moot point at the moment. For at least the next 6-12 months--and possibly for longer--AOLServer is the only viable platform for OpenACS, as far as I can tell. I don't hear anyone arguing that mod_aolserver is anything more than a marketing tool to help increase mindshare for OpenACS on AOLServer. So that means solving the AOLServer community problem has to be a high priority.

13: Response to Future directions for OpenACS (response to 1)

Posted by Don Baccus on 02/05/01 05:15 AM

Keep in mind that the AOLserver community and the ACS/OpenACS community are not one. At least some of those wanting to fork off AOLserver aren't part of "our" community over here.

To be honest, I'd underestimated just how badly Kris/AOL have handled things, if that's possible. I mean, I kinda knew, which is why I stuck it to him in private e-mail after he unjustifiably abused Jerry Asher in the public form. But I ducked out of the community months ago, mostly due to Kriston, partly due to other demands on my time.

It's far worse than I thought.

There will be more news in a few days.

Java ACS 5.0 will be vastly different than Java ACS 4.0. One of my concerns is that aD has never managed to put out a solid, usable, stable ACS release of any flavor (though I've not looked into the UI and other improvements in 4.1, I'm willing to be pleasantly surprised but am not counting on it). Now there's dilution of resources, which in my mind means that Michael's right when he talks about Java ACS 5 being 12 (not 6) months away in any solid, comprehensive form.

Java ACS 4 is a dead end. So is the Tcl ACS 4, but at least we know the basic AOLserver+ADP/Tcl framework works and works very, very well.
We don't know that about Java ACS 4.

And frankly I'm not going to have time to worry about it. As the ACS 5 picture starts to become clearer, we'll have a better handle on what it will take to port it. aD is very interested in supporting at least one Open Source RDBMS with ACS 5, so there should be help available as the project gathers steam.

14: Response to Future directions for OpenACS (response to 1)

Posted by Ryan Campbell on 02/05/01 01:58 PM

Java ACS 4 is a dead end. So is the Tcl ACS 4...

What do you mean by dead end? Will a 4.x installation not be upgradable? Or is 4.x just not usable? The phrase "dead end" has some horrible connotations.

15: ACS 4 Java beeing a dead end (response to 1)

Posted by Malte Sussdorff on 02/05/01 02:59 PM

"ACS 4 Java is a dead end, because it is just an easy to use port to Java, which maintains the look and feel of the TCL Version. Next to none of the enhancements that Java offers seem to have been used."

This information is from one of my students at university as I did not check it out myself. I can't imagine on the other hand, that AD is going to continue with this approach when building the next version (ACS 5.0) => Dead end, as all modules will need to have rewritten again.

16: Response to Future directions for OpenACS (response to 1)

Posted by Edmund Lian on 02/05/01 03:57 PM

Don's point that OpenACS could be a "big tent" project, where people work on the flavor (AOLserver/Tcl, Apache/tomcat/Java, etc.) of interest to them is surely one of the main reasons behind the success of open source development.

My fear however, is that the community is not large enough to put a critical mass behind each flavor supported. While it is true that the flavors without critical mass will simply wither and die, it is also true that this dilution of resources can threaten us as a whole.

Michael's point that companies tend to choose platforms based on ease of obtaining resources is a good one. I've lost work simply because the client, while impressed with AOLserver, had a "legacy" Kiva environment, used Perl, didn't know Tcl, and wanted a more mainstream solution. It's interesting that in trying to sell AOLserver/Tcl, I've hit the problem of trying to sell into what amounts to a legacy environment, even though the web is only 5 years old!

Fundamentally, I think putting AOLserver/Tcl into a greenfield environment is not a problem. However, trying to pitch it to people who already have some investment in web infrastructure, no matter how rotten it is, is a lost cause.

From a technical perspective, I'd like to stay with AOLserver/Tcl. However, the reality of the market suggests we might all be better off migrating to a platform and language that integrates more easily into the most dominant platforms around. This appears to be Apache/tomcat/Java or even Apache/mod_aolserver (disregarding the problems noted in this combination).

Up until now, I've not used the ACS code, and have been developing an in-house solution. The AOLserver/Tcl combination was not a problem in this instance. Now that I've started to develop for external clients and need some of the functionality in ACS, the issue of where to focus my efforts rears its head. In these external client situations, the only reason for wanting to use AOLserver is because ACS has been tied to it. But selling AOLserver into a legacy environment is tough. I'd have a much easier time if ACS were independent of AOLserver, or if AOLserver were much more widely known and accepted.

If we wish to continue with AOLserver as the base platform, then it appears like we need a fork so that it can evolve more freely in response to our needs...

17: Response to Future directions for OpenACS (response to 1)

Posted by Michael A. Cleverly on 02/05/01 06:42 PM

Getting any flavor of the ACS into an existing organization that only wants to use the tools or languages they already have in place will always be difficult if there is not an ACS flavor that maps directly to the tools they are currently using. ACS Java and ACS Tcl do no good for a company that believes all web development should be in (ASP | VB | PHP | Pyton | Perl | CFM) for instance.

Now, it's true that there are probably more in-house projects using Java (since it's more in vouge) than Tcl, so ACS Java meets a larger portion of the folks with existing infrastructure who don't want to learn anything new than Tcl would.

Personally, I hope development of ACS Tcl continues. The "quote of the week" on the comp.lang.tcl newsgroup this past week was: "I've come to the realization that there are so many more Java jobs than Tcl jobs because it takes 10 Java programmers to do what I can do in Tcl." There are folks out there with Tcl web/db experience--it's just that a lot of times they call themselves Vingette developers. 😉

18: Response to Future directions for OpenACS (response to 1)

Posted by Louis Gabriel on 02/06/01 12:02 AM

Hello Everybody,

I just went to DICE.COM, the site listing tech jobs. A search for TCL got 1042 listed positions returned out of a total of 128,225 site listings. JAVA returned 25,478; C++ returned 34,104.

Like many, I wonder what to allocate precious learning time to. A lot of the tcl jobs were fairly decent paying. Several listings I clicked on seemed to be seeking someone who knew how to test with tcl. Not sure how much tcl was sought for development .vs testing.

It seems to me that tcl is not dead. It seems there are positions out there for those who know tcl. How much so as a tool to do one's job (i.e. testing, one-time-only-stuff) .vs as the main development language would require much more time to research than I have to spend at this moment. JAVA of course does have LOTS more jobs available.

Also, I recall reading a study several moons ago that compared the productivity of scripting languages like tcl with languages like JAVA.

If I remmeber correctly, developers using scripting languages completed the same task in HALF the time it took to develop in JAVA.

JAVA is all over the place. I plan to work learning it into my schedule. But I guess one factor to consider is whether one's interest is more "what can I use to maximime what I can produce for a client as a independent contractor for what I can charge for the project" .vs "what will it be easier to get a paying job developing in". The one that I wonder about is "which one -- tcl or JAVA or whatever -- will make my services/product most marketable and at what price/rate".

Guess part of the "answer" for each person involves whether one wants to work independently or whether one wants a paying job internally to some company (brick-and-mortershop?).

Your thoughts?

Best wishes,

Louis

19: Response to Future directions for OpenACS (response to 1)

Posted by Ben Adida on 02/06/01 12:29 AM

They say that timing is everything. In this case, I would agree. The community has been relatively quiet for months. Then, Ben, Malte Sussdorff, and myself are holed up in Brussels when all of the action when down on the bboards. My mailbox gets slammed with 100 messages. And I can't answer them. How ironic.

I just stepped off a 10-hour flight & i'm a bit loopy, but i'd like to respond to what's going on at ArsDigita, and with the openacs, as best i can. First, the future direction of aD. I think that the unease that many of you are feeling is due to a decreased degree of transparency with the development process at aD. That is, in ye olden days, philip, jin tracy, et al, would be constantly blabbing on the bboards, keeping you up to date with the latest ACS minutae. This is no longer the case; the majority of the developers working on ACS don't seem to post as frequently as the old-timers. This may be due to personal choice, or to the severe time constraints that they are under , or because of some other reason that i'm not aware of.

Regardless of the reason, it's clear to me that our current development plan isn't well-known to the community.

When i recover from my jet-lag coma, i'll post everything that I know about what's going on. My hope is that with a little clearer vision, everyone will feel reassured.

The OpenACS is a different matter. Ben & I spent a great deal of "quality time" together these past 5 days (ugh.. it was like being trapped in a sitcom, a blur of travel & wacky misadventures..)

At any rate, drawing on the meeting that we had with Don Baccus in cambridge earlier in the month, i think that we have a the beginnings of a plan for OpenACS 4.x.

Do not underestimate the importance of moving OpenACS to 4.x regardless of what ArsDigita does: the 4.x series has a "package manager" which will, for once and for all, allow people to _EASILY_ write discrete modules for the OpenACS without fear of them randomly breaking or being stepped on by other modules. This addition to the project will finally allow for rapid development of the OpenACS as a "platform".

Ben is meeting me in Atlanta tomorrow to discuss this stuff some more.

He will announce the OpenACS plan, and make another announcement, at the Atlanta Developer Event on wednesday.

I will go collapse now.

20: Response to Future directions for OpenACS (response to 1)

Posted by Krzysztof Kowalczyk on 02/06/01 12:33 AM

Seems like Adam (?) and Ben switched personalites for good :).

21: Is Ben Adam or is Adam Ben? (response to 1)

Posted by Michael A. Cleverly on 02/06/01 12:33 AM

This is too funny... earlier in the thread we had Ben using Adam's laptop and writing as Adam. Now, I strongly suspect that we have Adam writing as Ben.

... Ben & I spent a great deal of "quality time" together these past 5 days...
Ben is meeting me in Atlanta tomorrow to discuss this stuff some more...
— Ben Adida

😊

22: Response to Future directions for OpenACS (response to 1)

Posted by Adam Farkas on 02/06/01 12:34 AM

Ooops -- now my turn to screw up.

That last post was from me, Adam. Not Ben. Ben apparently didn't log out of my box after he was finished with it....

(shame on him... 😉 )

returning to my coma...

23: Response to Future directions for OpenACS (response to 1)

Posted by Krzysztof Kowalczyk on 02/06/01 12:35 AM

Or maybe Adam and Ben are in reality ex-Tyler Durden?

24: Response to Future directions for OpenACS (response to 1)

Posted by Michael A. Cleverly on 02/06/01 12:36 AM

You guys should know better than to check the "save my password" box on a shared computer! 😉

25: Response to Future directions for OpenACS (response to 1)

Posted by Michael A. Cleverly on 02/06/01 12:48 AM

Adam, pretending to be Ben, wrote:

"I think that the unease that many of you are feeling is due to a decreased degree of transparency with the development process at aD. That is, in ye olden days, philip, jin tracy, et al, would be constantly blabbing on the bboards, keeping you up to date with the latest ACS minutae. This is no longer the case; the majority of the developers working on ACS don't seem to post as frequently as the old-timers. This may be due to personal choice, or to the severe time constraints that they are under , or because of some other reason that i'm not aware of."

I think you've probably hit the nail right on the head here. It's also kind of ironic that the only time (to date) Mr. Allen Shaheen, CEO of ArsDigita, has posted to any of the bboards is to answer the prennial "Where's Philip" questions.

A simillar "longing" for more direct, involved communication also lies at the heart of the recent brouhaha on the AOLserver developers list, in my opinion. (For instance, Jim Davidson doesn't ruffle feathers like Kriston does.)

Anyway, I look forward to the upcoming announcements.

26: I am Tyler Durden (response to 1)

Posted by Ben Adida on 02/06/01 01:05 AM

For the record, in this whole personality showdown and
schizophrenia extravaganza, I am Tyler Durden. Your jetlag
excuse is weak, Adam. Atlanta, here we come.....

27: Response to Future directions for OpenACS (response to 1)

Posted by Don Baccus on 02/06/01 04:28 AM

When I described Java ACS 4.0 as a "dead end" I meant it strictly as Malte suggested, i.e. the datamodel and everything else under the sun will change to the extent that modules will be rewritten again to fit.

I think it's clear that our first priority will be to put together a Tcl 4.0 port.

When or if (most likely when) an OpenACS Java version comes out, odds are it will make the most sense to just do ACS 5. We'll see how their development schedule unfolds.

I don't consider OpenACS Tcl 4 version a dead end in the same sense because, ironically enough, there will be no Tcl ACS 5 from aD. Yet I think there will be plenty of interest in it, still. So I think it may well continue on with a life of its own.

However, it will be a dead end from aD's point of view, someday. Java is clearly the future path. But the Tcl stuff will be around for a long time. aD's not going to attempt to switch all their client sites to Java, for instance. That would be insane!

28: Adam <-> Ben (response to 1)

Posted by Mohan Pakkurti on 02/06/01 09:23 AM

They seemed to be themselves in Brussels, but they were disenchanted with high tech stuff like mobile phones with IR ports and GPS?!?

Anyway... It was great to meet the aD guys, and Ben at OSDEM. And Ben's talk was concise and effective and the demo was impressive also. But we are used to that kind of functionality!

At OSDEM I talked to some people who are considering using OpenACS and offered help with installation and configuring if needed. Hopefully it generates some more interest in OpenACS.

Now it is time to prepare for the arrival of the 4.0, so we can go crazy porting them modules :)

29: Response to Future directions for OpenACS (response to 1)

Posted by Brett Schwarz on 02/08/01 08:03 PM

I have been using OpenACS now for the past 6 months. I really enjoy it. However, my company wanted to go to Java based application servers, so we started working with Apache/Tomcat. I was excited at first, because it was going to give me a chance to work with Java, since I only messed with it a couple of years ago; and there is so much press about it. However, after about a month or so, I don't ever want to develop web apps in Java, again. It does take seriuosly about twice as long. I just think it is the wrong tool for the job, *IMHO*. I hope that OpenACS does not go to Java, because I think I will look elsewhere then.

Note that I am not a language bigot; I think Java has it's place; I just don't think it is in the web app field.

Unfortunately, I think this whole thing will turn out to be a business decision against a technical decision.

30: Response to Future directions for OpenACS (response to 1)

Posted by Don Baccus on 02/08/01 09:07 PM

Well, even though we'll almost undoubtably end up with a port of the Java version, that doesn't mean we have to use it ourselves :)

31: Response to Future directions for OpenACS (response to 1)

Posted by Stephen . on 02/08/01 09:39 PM

What is the objective of the OpenACS project now that Arsdigita is changing direction? Is it a least effort port of ACS to an open source databse?

Like others here I don't relish the idea of developing websites with Java. I just don't have that kind of time, and damn it, it doesn't look like fun. Neither though do I want to be stuck with some end of line product that's going no where.

Is this the end of the road for the ideas in The Book? Should I be looking somewhere else?

32: Response to Future directions for OpenACS (response to 1)

Posted by Don Baccus on 02/08/01 09:58 PM

Well, Ben (read above where he thinks he's really Adam) and I both have stated our own personal interest keeping the current Tcl-based ACS alive and well. Given that, it is hard to imagine it dying.

On the other hand, ACS 5 and Java will probably appeal to a lot of people. Somewhere around here I mentioned my belief that OpenACS can be a "big tent" project. Those interested in the Java version will undoubtably port it. aD has an interest in seeing it done, at least at the moment. I think I probably want to see it done, too, though I'm not quite sure why - I'm just ornery, I guess. So I'll probably pitch in, too.

But I personally don't want to see the Tcl version go away, and I personally intend to work with it and enhance existing modules and write new ones as well as time permits.

I also recognize that the Java version might help my friends and I land more business. Of course, telling folks that aD made the big switch to the Java/servlet model after Philip left and that we still think "The Book" had it basically right and we're standing on our track record might help us land more business, too...

33: Response to Future directions for OpenACS (response to 1)

Posted by David Eison on 02/09/01 07:24 PM

<blockquote>> "I don't relish the idea of developing websites with Java."
</blockquote>

I didn't either, but to be honest, with a good templating system and some sort of script-like recompile-pages-on-the the fly capability (i.e. JSP), it's not nearly as bad as you'd expect, and it is nice to have lots of tools/other code to draw on + compiler & junit to help track down stupid mistakes. There are still more tools to be written, of course (good system to check/translate/recompile every page, in particular), but I've already seen big wins in my personal development with the existing tools.

I've worked in each and I think that Java can be made to be nearly as quick to write as Tcl (whether through custom extensions or industry standard extensions; everybody their brother and his pet dog sparky seems to be developing extensions and templating systems and scripting languages for Java web development these days, making it clear that plain Java isn't the right thing to do web pages with but tools that translate into Java can be pretty darned useful), and I sure as heck would not have said that a month ago.

It's interesting to note that the other big TCL-for-creating-websites user I'm aware of, Vignette, has switched to Java: <A HREF="http://www.vignette.com/CDA/Site/0,2097,1-1-731-1191-1282-1909,00.html#support">http://www.vignette.com/CDA/Site/0,2097,1-1-731-1191-1282-1909,00.html#support</A> It's hard to tell how it's gone since their "Technical library" is restricted, but here's an interesting quote to demonstrate the intelligence of technical analysts: "While previous versions of Vignette's software have had impressive functions, the company has lost business to rivals because customers didn't want to deal with its difficult-to-use programming language, Warzecha said. Vignette 5.6 should eliminate that handicap, he said." (http://industry.java.sun.com/javanews/stories/story2/0,1072,32855,00.html) - I say intelligence rather than stupidity because, as sad as that looks to all of us, I'm afraid it's an accurate statement and the analyst is probably dead on.

But in the end, it's a business decision: Writing something that will stand on its own and nobody else will ever see it? Use whatever you like (isn't that an argument for mod_perl? :) ) Want someone you've never met before to have a prayer of understanding it, without wondering why "# } blowup" is interpreted and dies even though it looks like a comment? Well, they're probably familiar with Java... and they may have an API you can use to speed things up, too.

Please understand I'm not trying to start a flame war, just saying that it's not the certain doom some seem to think it is. :)

34: Response to Future directions for OpenACS (response to 1)

Posted by Robert Locke on 02/19/01 08:04 AM

So, am I correct in stating that OpenACS 5 will have both a Tcl and Java version? I like the "big tent" concept of supporting both, but I wonder how realistic it is. Is the community really strong/large enough to do this? I wonder if diverging interests will cause the OpenACS to "fork" from the ACS ala OpenNSD/Aolserver.

Do we have a roadmap that atleast attempts to answer these questions ala http://www.arsdigita.com/file-storage/download?version_id=20941
?

But, perhaps it is too premature to ask these questions and only time will tell.

35: Response to Future directions for OpenACS (response to 1)

Posted by Don Baccus on 02/19/01 04:36 PM

No, ACS 5 won't have a Tcl version. I suspect, though, that there will be folks who will be satisfied with ACS 4 and will continue work on it. Just as people are still fixing OpenACS 3.2 today. ACS 5 won't be "real" for many months, so presumably there will be real sites developed with OpenACS 4/Tcl. Once real sites are up, needing to be extended and maintained, there will naturally be a desire to continue improving the toolkit.

36: Response to Future directions for OpenACS (response to 1)

Posted by Adam Farkas on 02/19/01 04:39 PM

Don is correct; even the most optimistic timelines don't see ACS 5 being pushed out the door for several months.

With the implementation of the package manager in OpenACS 4, I suspect that you'll see that platform be the target of enhancements & modifications for a long time to come.

37: Response to Future directions for OpenACS (response to 1)

Posted by Roberto Mello on 02/19/01 04:49 PM

That's probably why we don't see much effort from aD to port 3.4 packages to 4.x. It's all going Java anyways, why care about Tcl?

One more reason to get OpenACS 4 out there.

38: Response to Future directions for OpenACS (response to 1)

Posted by IDiscovery Support on 03/15/01 04:48 PM

Firstly a comment on mod_aolserver: it's performance is pathetic.
I'm new to ACS, so I've been just installing and testing a demo setup
on a small Linux box, and a single ACS user was taking about 130M virtual with mod_aolserver and 30M with aolserver. Although the
install procedure for OpenACS/mod_aolserver is a work of art, mod_aolserver cannot be the way to go, at least with Apache 1.3.14.
Has anyone benchmarked these with ApacheBench?

Secondly, I don't think it's a coincidence that both Vignette and aD
are both dropping Tcl for Java. Now that Ajuba/Scriptics/SunLabs went
under, I think all companies whose existence is at state will bale on Tcl, either because their clients do indeed demand it, or just because at Internet speed, mindshare is important.

I also think Java is a really poor alternative, especially for ACS type of applications. So a part of the question is: if for technical reasons we don't want to get on the Java bandwagon, what are the alternatives? The answer will be judged not only by technical merit, but by looking into a crystal ball to see what will have mindshare 3 years from now.

I'd like to point out one alternative. It may seem off the wall if you don't know the components well, but I advise anyone who doesn't to invest some time into checking it out.

PyWX (http://pywx.idyll.org or pywx.sourceforge.net) runs Python under aolserver, and gives complete access to the Tcl C level API. Unlike Java, Python is a *great* language for writing web pages, probably even better than Tcl. Python also has excellent DB connectivity, as well as good XML handling (much better than Tcl). And the performace figures of aolserver/pywx that they showed at the Python9 conference were astonishingly good.

So the possibility exists with Python in under the aolserver, to
rewrite Tcl modules slovly over time in Python, with 100% interoperability with Tcl on aolserver. So if OpenACS is to break away from ACS, whether because with ACS 5 there will be 'Open' DBs supported, or because coding in Java just won't suit many of us for rapid prototyping, then maybe Python is the way to go for OpenACS.
All Tcl projects I've seen ported to Python have benefitted in the translation.

It might even be best to save the effort of the 4.x port and build Python translations now on the OpenACS 3.2.4 base.

39: Response to Future directions for OpenACS (response to 1)

Posted by Jonathan Ellis on 03/15/01 05:12 PM

Maybe I'm totally smoking something, but I actually like tcl. :) Perhaps it's because my short term memory is worse than the next guy's, but tcl's minimalist approach is really appealing to me. Sure the rules are unusual, but they're totally consistent. I really do believe small is beautiful. :) I don't think I'll move away from tcl as my web scripting language of choice any time soon.

I did take a look at the PyWX page and the examples really don't strike me as, "OH WOW LET'S REWRITE EVERYTHING IN PYTHON." It seems to me that AOLServer's C API isn't nearly as useful as the tcl API, particularly when you add all of aD's work to the tcl side.

It's great that Python is an alternative to TCL and JS, but I don't see any compelling reason to do a rewrite in that. I could see writing some pages / modules in python where more complicated processing has to go on than "grab stuff from the DB and write it out," because let's face it sometimes lists of lists and associative arrays just aren't enough. But OpenACS isn't ACS and I don't see us wasting thousands of man-hours rewriting something that works perfectly well.

40: Response to Future directions for OpenACS (response to 1)

Posted by Ben Adida on 03/15/01 08:04 PM

You are forgetting that the ACS/OpenACS is much more than the Tcl scripts. It is also the underlying data model, a fact which is significantly more important in the 4.x architecture with the object model. The port to 4.x is important because it makes the system significantly more open-source friendly through its modularity. Porting 4.x *plus* moving to Python would be a huge added burden.

Remember also that we have a community of thousands of users who know and understand Tcl. Tcl isn't broken. As a language, it doesn't need to evolve. Functionality can easily be added through AOLserver/Tcl C extensions like ns_xml (which I believe contradicts your point that we don't have good XML capability in Tcl).

You're right about the idea of mindshare. Mindshare is important. But I think most developers in this community are more interested in mindshare in the field of enterprise-level web applications, and not so much in being the unknown hero of a language war.

Certainly, I'm psyched to see people developing Python support for AOLserver. I'm personally interested in web architectures. Python support in a multi-threaded environment is a great new way to build web applications correctly. But it's not so superior to Tcl (if at all) that I personally want to port all of my code to it. And if you and a series of other developers want to make this Python project happen, you're more than welcome to! We'll link to your project and I will consider it a wonderful development for the OpenACS community. But there's no reason for the core development right now to change direction so radically only because of language preference.

41: Response to Future directions for OpenACS (response to 1)

Posted by Pedro Lima on 03/19/01 07:01 PM

If in the near future the community could build a python ACS, that would be a killer app for pyworld.

I've witnessed the rise and (in my opinion) fall of Zope (Python App Server, object publisher, etc). There are a lot of pythoneers that want to delete Zope from their computers and so a lot of new projects were started (modsnake, modpython, webware, Quixote, etc).

But it's a lot of work to port ACS. Maybe some company could invest in that port and build a business model out of it (Digital Creations, makers of Zope (C) got a river of cash with their (quite inferior?) product). Mean time I guess pythoneers could help the PyWX project, right?

42: Response to Future directions for OpenACS (response to 1)

Posted by Jerry Asher on 03/19/01 07:24 PM

Pedro,

Can you give some pointers about the "fall of Zope". I was playing with Zwiki last week and liked it a lot and was contemplating putting time into Zope, especially considering that the marketability of a Python/PostgreSQL or Python/Oracle solution could go far to mitigate Tcl's marketability problems. But before I do venture into Zope, it would be nice to know beforehand that it was thriving and not dieing, or that it was a promising path and not just a technical deadend for whatever reasons....

For IDiscovery Support, if PyWX gives one complete access to the Tcl C level API, that is wonderful. State in an AOLserver/OpenACS app is largely kept in three locations: cookies, the database, and nsv arrays. If PyWX can get access to the nsv arrays, I would think that means that a PyWX module should largely interoperate with a Tcl module, although I suspect Tcl can't call into python or vice versa.

Unfortunately, I believe that the PyWX developers state that PyWX is not ready for production use, but um, I would love to see Zope/Python stuff appearing for OpenACS.

My suggestion then is to ask you to help us understand the issues (before asking us to convert). If you port some modules from the Zope/Python world over to the ACS world (Zwiki comes to mind :) I think you'll see a lot of us try those modules out.

(By the way, I am not trying to chastise you, but I think community works so much better when folks not hide under a veil.)

43: Response to Future directions for OpenACS (response to 1)

Posted by Mike Linksvayer on 03/19/01 08:09 PM

Regarding the "rise and fall of Zope", a comment I made on slashdot a few days ago and some responses to it may be relevant. My comment:

http://www.oreillynet.com/pub/a/python/2001/02/22/pythonnews.html says
John Udell once described Digital Creations' Zope as Python's killer app, the application that was going to have everyone scrambling to learn Python. It hasn't proved to be much of a killer though. Web designers looking for solutions to their documentation management problems routinely dismiss it as overkill, developers as underkill, or too hobbling.
I haven't taken much more than a cursory look at Zope (several times over the last couple years), though that's about the impression I got: too much complication for too little gain.

There are already numberous alternative offerings for Python. I'd target Ruby instead.

44: Response to Future directions for OpenACS (response to 1)

Posted by Pedro Lima on 03/26/01 05:42 PM

Note to jerry asher: I never signed as IDiscovery Support (you missed), but I guess I have the similar opinions.

About the fall of Zope. Of course it's my opinion, but I based it in several facts. In the article mentioned above John Udell tells that people at Digital Creations are doing heavy thinking to redesign Zope to make it better for python developers. If they are doing it it's because they think they are not (yet?) in the right direction (right?).

Also, when Zope was made open source all (or nearly all) python web projects stopped and everybody started using Zope (myself included). In the last year a lot of action started in different directions from Zope. Here is my list of new python ways to develop a web site.

Webware is a app engine written for python. I tried it and it feels like the Java Servlet design ported to python.
Mod_python is like modperl, persistent python in the apache server. I like this one.
mod_snake another persistent python in the apache server, more targeted at apache 2.0
PyWX you all know this one.
Quixote uses only the zope object database.

Also many people wrote articles with titles like "why not zope".

In my opinion it's a lot of people looking for a better direction (maybe not too different from what's going on at openACS and aD). In my opinion this means "the fall" of Zope, but I can be wrong.