Forum OpenACS Q&A: Re: New openACS user...confused

OpenACS is first a toolkit for building applications. The applications generally have an HTTP interface provided by the AOLserver. That is their similarity to websites. However, unless you were going to punt all you know about web development, I don't know that I'd advse it for building mere websites. I've been using it for a year now, and I still don't understand some things that are pretty basic to some members of the community.

If it were just a neat way of using TCL from a webserver you were looking for, you've come too far. Go back 100 yards and pull into the AOLserver parking lot. It's a darned fine webserver. With the exception that it doesn't have dumb-simple virtual hosting, it's probably the best webserver I have seen. The fact that PHP and Perl aren't trivially supported is a plus in my book :)

Now, to understand OpenACS, I believe you need to grok the notion that little you do in the filesystem matters. What matters is that you get everything running, and by interacting with the administration interface, you construct a hierarchy of subsites, mount applications onto these subsites, and change their parameters. At no time do you directly create files in the filesystem. This last has beem my greatest difficulty in coming up to speed with OpenACS. It may be that for a particular situation, one needs to create a file on the filesystem. However, I've never gotten a clear answer on when and where that is.

Anyway, after I started this reply on Friday, I realized that I might be able to contribute to this little dance party here. I created some movies of the configuration of OpenACS from the point where the AOLserver and OpenACS kit are installed and ready to go. Now, getting to that point isn't trivial. In general, "You can't get there from here." the Debian version of GNU/Linux has a ready to run kit, I believe, as does FreeBSD. I use Solaris, so all bets are off. The intersection of Solaris and OpenACS users may well have been the empty set before I came.

So, if you'd like to see how the initial set-up and config of a site, sub-site, and user go, go to http://www.webrelay.net/download/oacs/ and grab the three avi movies there. I think they'll be helpful. A warning: The videos are not compressed. I'd welcome a private note as to how to do that. They are also not ready-for-prime-time. More like dress rehersal. I hope to revise them soonish. Oh, and if you'd like to get this kit up on a Solaris/SPARC system, the svr4 packages in that dir will get you going. You'll probably want to get them with wget or fetch, as they are dirs, not files.

Anyhoo, I realize that this doesn't answer all of your questions, but I hope this helps.

Cheers!

This needs illustrating in the docs. The *only* way I found it was by tracing the executable while giving it non-extant uris.

If one creates a subsite, say newsite, and mounts packages foo, bar, and baz at that subsite, then the following uris will be valid:

www.site.dom/newsite
www.site.dom/newsite/foo
www.site.dom/newsite/bar
www.site.dom/newsite/baz

while the uri, www.site.dom/newsite/zot will not be. No surprise so far.

Now, create the dir /www/newsite and edit therein the file zot.adp, and voila, www.site.dom/newsite/zot is no longer 404.

What this all means is that uris reference files until a uri pattern matches something stored in the database. Then the magic works.

I'm still of the opinion that creating a subsite should make the appropriate dir in /www. And that removing it should optionally remove the dir. But I can script around this.

Now, if I can figure out how to move /www out of the oacs dist filestruct, I'm golden.

Cheers!

Sam and David,

If either of you are interested in looking under the hood of openacs a bit and don't mind getting your hands dirty and editing some files in your favorite text editor, might I suggest the developer tutorial?

It shows a bit of how openacs works and how to create a package, mount that package, write scripts that install and remove the data model for that package and how to prompt the user and store and retrieve results.

Customization of openacs much beyond creating and mounting apps, setting parameters and granting permissions requires programming, and that's what the tutorial introduces.

The developer tutorial is appropriate for just that: developing packages. There isn't a tutorial for *using* OpenACS. In fact, a great frustration that I have is that to *use* OpenACS, it is a bit difficult to follow the directions, and still *use* my favorite text editor. This forum is a classic example. I'm using a screaming hot computer, running Solaris, with vendor supported emacs (Wahoo!) on the side. And yet I'm typing this note in a tiny screen, and wondering how it will turn out! Troff, anyone? This is akin to the suggestion in the docs to create a home page for your brand, spanking, new OpenACS install by firing up ETP. And even then, there is no suggestion as to what to put in This Edited Page. FWIW, the acs-templating guide doc/acs-templating/demo/ is most helpful. But it's hidden in the docs.

Hey, my hands are filthy with OpenACS muck on them. And I still feel that it's the best thing going, all things considered. But the standard kit has a few nits, that if fixed, would make the kit much easier to grok for a wider user base. And yes, by fixing, I mean easing the use of the OpenACS as plain webserver as needed. Really, there's a tremendous amount of high-quality, ready-to-run code in the OpenACS kit. One ought to be able to just use it.

But, as I noted above, I've got my workaround. And on Monday, I'm going to show a static website developer how to add an OpenACS forum and journal to her website, and neither one of us will program a thing!!!

Cheers!

Heh, Would that all the world had a .el interface!!! I generally use what's at hand. The context switch is too great when I'm reviewing a set of posts to switch over to emacs and then back to the web browser.

Forums are nice as a record of a specific conversation. Email lists are better transport mechanisms for those conversations, I think.

I'd propose a solution, but you beat me to it in this message: http://www.openacs.org/forums/message-view?message_id=389793

And very nicely, too.

Cheers!

Heh! Nothing significant. Heh! The significant bits (where The wle thing cam crashing down on the floor with random bits rolling everywhere) are indeed what are missing. But I had a fair bit of trouble getting those pieces right. The lack of a concrete example was a pain. So, now there's a concrete example.

As far as Solaris is concerned, I don't use Zones, Jails or chroots of any type unless I'm desperate. The headache to me is not worth the benefit. But SMF, not that's much nicer than I originally thought. I am currently running ACS as a "Legacy" init.d script, but I've done a bunch of work to figure out how to migrate. I've already got postfix, thttpd, and a home grown pop3 server running under SMF. Perhaps I'll start a Solaris thread here to post my experiences once I get the ACS (well nsd) running under SMF.

Cheers!