Forum OpenACS Q&A: Top Ten Priorities for OpenACS ... what are yours?

Definitely:

Produce and maintain automated testing suites for all core packages. I have been using the automated testing package in developing WebDAV support and it is greatly helpful.

Tcl API for the content repository. A complete Tcl API, to reduce or eliminate the need to have pl/sql to access the CR in an application package, will facilitate building better user interfaces for Content Management.

Before we upgrade openacs.org to 5.0 we need to upgrade to 4.6.3! Hopefully done before the 5.0 release.

Alfred, thanks I forgot about using standard tcl packages. That is a great idea.

Random thoughts, no order, trying not to repeat things already said:

• Small perl/bash script, that will upload a patch to openacs like this "upload-openacs-patch #bugnumber #filename(s)". In other words, make it as easy as possible to provide patches to OpenACS
• Knoppix CD with OpenACS out of the box.
• Structured approach on OpenACS marketing.
  • Creation of OpenACS marketing material
  • @openacs.org emails
  • signup OpenACS to conferences (and try to get reductions).
  • Coordinate press releases about OpenACS. Installation of a press module for monitoring all published information about OpenACS on openacs.org
• Expand the user base.
• Talk about work that is beeing done, try to avoid double developement.
• Single signon gateway which would allow us to easily use e.g. squirrelmail as a webmail system or integrate other systems.
• Install Jabber functionality in openacs.org
• Sort out and resolve the CR discussions
• OpenACS social beginning of next year in Germany

Is it possible to convert (or hack aolserver) to write log files in XML format, then pass this through a streaming parser
to dynamically generate meaningfull log reports based on some user specific parameters?

http://opera.inrialpes.fr/people/Tayeb.Lemlouma/Papers/Web%20Server%20Logs%20Analyse%20Using%20the%20XML%20Technology.pdf.

Nagita,

I read the paper (quickly) and here are my thoughts:

1. I was referring to the "error" logs, rather than the access logs.
2. Most sites don't bother with realtime reporting on access logs, rather, they roll them daily and run report software against them (largely due to size). While this would allow a means of providing realtime logs, the bloated size of already overlarge log files would be too much. I'd rather see them go the other way - normalize the acccess data.
3. If we converted the access logs to XML then only one piece of software could read them. Currently there are at least dozens of good packages out there to do whatever reporting people want.
4. I can code XML but not XSLT.
5. I don't have a personal need / desire to see it happen.

I'm not sure if Joel intended for this to turn into a general wish-list thread. We have plenty of those already.

I'd really like to hear what people really, seriously think are top priorities, the most urgent ones. The things that would help the software mature and the community grow.

My personal list is very similar to Joels, but I've added some reasonings:

1) Release 5.0 (software only matters when you ship it)

2) Test 5.0 (we've found too many trivial bugs lately)

3) "One-click" install (people need an easy path to test the software

4) Automated testing  (improves quality)

5) Documentation improvements (distribute best-practices, improve quality, get more people contributing)

6) UI standards and improvements for applications (makes our software more usable and useful)

7) CMS UI (most sites start with CMS, and we're so close but no cigar)

8) Upgrade OpenACS.org to 5.0 (many important new things, it's important that we get openacs.org back to the trunk)

9) Fixed 3-month relase cycles (gets us in the habit of shipping, lets our users know what to expect, helps users not fork from releases)

10) Solving the metadata riddle (we have so many half-complete data dictionary/metadata-style things, we need to get one and get it working)

/Lars

Well, there's nothing above that I can disagree with.  That's a good list up there, lots of crucial things.

Offhand, the only addition that quickly comes to mind is to continue our efforts to migrate more API stuff to Tcl to support rapid development.  In the past few months we've implemented high-level, declarative approaches to ease the defining of service contracts, portlets and applets and there's a lot that could be done with the content repository that would make the writing of content packages much, much simpler than it is today.

I would like to see us define coding standards and to move existing packages towards using them.  I'd love to see all forms created by the templating package, for instance, preferably using ad_form.  We can do a lot to cut the learning curve that must be mastered before one can be productive using the toolkit.

My Top Ten:
- more usable forum,
- more usable filestore,
- more usable forum,
- more usable filestore,
- more usable forum,
- more usable filestore,
- more usable forum,
- more usable filestore,
- more usable forum,
- more usable filestore.

I think my priorities are:

• More duplicated functionality. We definitely need forums-lite-new and lite-forums-threaded to complement current packages
• Longer function names (eg. I find ec_price_price_name_shipping_price_tax_shipping_tax_for_one_item nowhere near descriptive enough).
• More deprecated procs, although said deprecated procs should be used pervasively in the toolkit.
• Service contracts are too easy to debug. We need to add at least two more layers of abstraction there for them to be useful.
• Our markup is too clean. We need more tables, we need much more hardcoded styling and more physical markup. html 2.0 transitional would be a good goal.

I agree wholeheartedly with Don and Joel here.

About package maintainership perhaps what we need is to clearly define how to become a package maintainer, or cease to be one.

In the Debian project this is done through submitting bugs. When a Debian developer plans to package a piece of software s/he submits a bug called an ITP (Intent To Package).

When a developer wants to "orphan" a package s/he maintains that s/he no longer can/wants to maintain, s/he sends a "ITO" (Intent To Orphan) bug. When a developer wants to adopt an orphaned package, a (you guessed it) ITA (Intent To Adopt) bug is sent.

All the other developers see these actions. What we need are clear instructions on an easy-to-access place on how one can go about taking maintainership of a package and what that entails. Perhaps we could borrow some ideas from Debian in this regard.

That should probably go in the https://openacs.org/contribute/ page.

-Roberto

1.  A forum especially for beginners. For some people posting to the forums is like a first year student being pushed into graduate Quantum Physics. There are 6000+ members but how many 'regulars'?

2.  A usable CMS UI. Just copy (legally) an already successful one and graft the functionality. Then put it in the 'out-of-box' version of OpenACS (along with some attractive design templates) so that new user can start adding content quickly/effortlessly 2 minutes after restart. Once this is there, they will find uses for the other 'dynamic' applications. The Redhat CMS UI looks good to me. Is it legal to take design cues from it?

It would be nice to have an IDE like Eclipse (eclipse.org) that could generate an openacs package. Any ideaas about how to go about this?

There will be a student in my lab (next year) working on EML (an educational modelling language) probably using ArgoUML. He might be working in getting the UML tool to generate things that could be used by dotLRN & openacs.

It's interesting to me that the post that started this thread says:

"UI improvements to bug tracker"

It's interesting because that's the reason I looked at the OpenACS site today in the first place. I was thinking about using access atributes in the href for adding new issues -- so you could alt-a to add a new issue or alt-shift-a to pop a new browser and add a new issue.

I wanted those options on the bug page and the bug-add page (so that users could save some keystrokes when they want to add more then one issue that relate to the same thing.)

My team just finished logging and resolving 380 issues in the ACS 3.2.5 ticket tracker, new-ticket. I like how the summary page could be sorted by Ticket type, Ticket assignment, Status, Creation Time, ID v, Project,  Status,  Severity,  Assigned,  Deadline,  Subject, (that little v lets you toggle between assending and decending order.)

The bug tracker in OpenACS 4.0 relates specifically to tracking bugs in software and releasing patches to fix them. I like how 3.2.5 ticket tracker doesn't relate specifically to software "bugs". It tracks "tickets", not "bugs". This gives it better range because, for instance, it can be used to track anything -- like your customer's requests or who your books are loaned too -- without being confusing to the people who use it for that.

So I guess I wish the OpenACS bug tracker had an easy way to change the verbage globally across the application -- instead of bugs an admin could call them "issues" or "tickets" or  or "service requests" or something else.

Hi folks,

1. From a users point of view, ask this same question to first time visitors of www.openacs.org, and put this prominently on the homepage. That will give developpers a sense of what John Doe is looking for, without getting distracted by technical challenges.

3. Make available all information about adding design features to the toolkit in a format normal people can understand. Right now I have to dig deep into the forum to find usefull information. Maybe we have some folks that have managed to do what the toolkit was designed for, and concentrated on design, rather than database development. I think you folks could add some very valuable information, that would help administrators and users of the tookit.

PHP nuke comes complete with a few default skins that can be changed by toggling. I can't imagine something like that is not possible with OACS, but, i havn.t got a clue about technology. Anyway, I thik it's a nice fature.

In general I think you are doing a great job, and once you get used to find creative ways to bypass problems, it all works fine. Thanks a lot.

Cheers
nontechie/Ben

1. Calls to noncore applications, such as ispell could reference a parameter or some kind of package config file with the ispell filepath.

The path to ispell is detected upon server startup. Isn't this solution preferred to a package parameter in acs-templating (where spell-checking belongs)?

Of course, if both ispell and aspell is installed on your box, aspell will take precedence. So if you'd rather use ispell in that scenario, you may accomplish it by uninstalling aspell from your os and then restarting the server.

/Ola

first, i wholly support jeff davis.

second, my suggestions deal more with the learning curve of oacs.

- gather the various, scattered openacs documentation and make sure it's all up-to-date.

- present a clearer community view of best-practices, methodologies, suggestions for site planning and development with oacs.  more examples.  encourage users to submit case-studies.  maybe set up a specific "educational" area of openacs.org for users to share their suggestions and experiences.

- require packages maintainers to document the scope, requirements, and status of their packages.  the community should "certify" packages (ie. a community-recommended package) by reviewing quality, completeness, qa-testing and value.  require package maintainers to document and communicate the status of their packages to the community or risk losing certification.  clearly document packages that are not certified, and what the ramifications are for using them.  encourage users to get their packages certified.

- easier install.  i've installed oacs many times on a few different platforms.  it's slightly tedious with plenty of finger-crossing.

- offer precompiled binaries for different platforms of the different software pieces required for installation

I think we should do that. We need package maintainers to foster and grow the sense of responsibility among OpenACS participants.

Doing it yourself is the safest of way of getting it done :)

I've been reading this thread with great interest, but I'm replying to Joel's query for input from newbies.

I think I qualify in that regard. I have been working with OpenACS for about five months, completely in my spare time. So I'm not yet productive as a developer, but I think I'm far enough along that I can see how things fit together.

As a result, there are three things that would significantly improve the functioning of OpenACS, as I would use it.

#1. Content-based URLs everywhere, based on position in the web hierarchy and the content of the object.

Currently, OpenACS presents many object URLs that include database query syntax involving the system-internal object ID. For instance, bug-tracker, forums, and file-storage all present a URL that includes that syntax.

By contrast, the edit-this-page package presents URLs that are content-oriented, which hide the object ID and the database syntax from the user.

This should be the system default: To hide the object ID, which is not meaningful to the end-user, and to present a permanent URL that is oriented toward the object's content.

Every OpenACS object has a "context," which consists of its position in the site hierarchy. Most objects also have an attribute that could be used to identify it unequivocally, based on its "content." For instance, every bug in bug-tracker has a bug number. The URL to bug #20 should simply be "myserver.org/path/to/bug-tracker/bug/20". Each forum could be given a "name", such as what edit-this-page has for each page. So the OpenACS Q&A forum could be openacs.org/forums/q-and-a. Each forum message could be numbered starting with #1, as qmail does with its mailing lists (ezmlm), so the first message in the Q&A forum would be openacs.org/forums/q-and-a/messages/1.

The advantage of doing this is not just to make a pretty URL for the user, but to make the public interface not depend on the underlying architecture. If I move my site to another installation, I shouldn't have to go through and fix all of the internal URLs to objects on my system -- not to mention breaking all of the outside world's links to my objects! In the case of file-storage currently (4.6.3), I have to fix URLs every time I upload a new revision, if I want to link directly to the most recent revision and not to the page that shows all of the revisions for the individual file. It would seem to be beneficial all around to ask every package to provide an "abstract" public interface like this.

#2. Extend Content Repository to use the File-System and CVS, rather than the Database, for content storage, if so desired, and put the resulting files in a hierarchy under www.

The metadata for each object would still be held in the content-repository, and perhaps the text-only content of the "live" version (for search purposes). But the option should exist to keep content objects themselves in the file system, in their "apparent" hierarchy, and to control the whole thing by CVS. This should integrate fully with the established standards such as use of the Content Repository. For some types of content (a community software development project, for instance!), this is a more practical way of storing things.

Just today, I discovered that File Manager package tries to integrate with CVS. It looks like dusting that off, and rebuilding it to use the Content Repository (and more fully use CVS), would be a step in the right direction. I want it enough that, if I can, I will do it; and if so I'll contribute the code.

#3. OACSH -- OpenACS Shell

It would be very useful, for trying things out and getting a feel for how the architecture is put together, to have a web-based "shell," by which a site administrator could executive arbitrary Tcl statements or SQL queries, and see the results in the browser. This might also prove to be a good administrative tool. I almost didn't mention this one, because it would seem to be pretty easy to implement (just eval whatever is input into the textbox, and return the result to the same page). Needless to say, this capability, while useful for the administrator, would have to be kept under lock and key (admin login should use SSL anyway, right?).

---

Okay, those are my "three wishes." I don't expect any OpenACS developers to be a genie, but I appreciate greatly all of the hard work and effort that has gone into making this such an outstanding system.

If I could add one more desire, it would be:

#4. Catch all database errors and display a meaningful error message that nevertheless shows the site template for that context.

It's unnerving to me when something doesn't work and I get a database error. Even if something is "not a query returning rows," it should display the site template and context in which the error occurred, and then within that framework a friendly error message, with full technical details below. This would help the occurrence of an error be more acceptable to the end user. It would also make me more comfortable publishing a site, because even if errors occur I know they will be tried, caught, and sentenced.

Okay, those are my newbie musings. Thanks for listening (since you've read this far!).

Take care,
Shawn

Derek and Shawn

THe content repository can store files in the filesystem. Besides that, you can write a CR application that publishes the live content merged with a template under the page root.

I am not sure of the advantages of using CVS to manage the content.

File storage content for postgresql, at least, is already stored in the filesystem under openacs-4/content-repository-files. This actually stores all the revisions under this hierarchy. Its transparent to the user of the site and the developer where the content is stored.

About content based URLs, this is also a good idea. I already wrote a very short index.vuh to be added to file-storage that will present files under the folder hierarchy with their filename, and will not require a revision_id. It always serves the live revision of an item. It can be made to also serve other revisions to file owners with an optional revision_id parameter.

This is a fairly straighforward thing to implement for most packages.

Shawn, we already basically did this for a CMS based on OpenACS 3.2.5. It worked pretty nicely, and you can download the code here

That being said, it's pretty unclear on what you're gaining from this that you wouldn't get from proper use of the CR. No one will really stop you since it would be an interesting project, but this sort of jumped out at me:

Use the database for metadata about the files. Model the object system on the OpenACS object model.

Why not just use the object system in the first place?

Further, since you're calling this a "poor man's webdav" why not just use the webdav code that is being built, which you can read about here?

There are some good ideas, but the project seems to dangerously replicate a lot of previous work...

talli

Hi Dave,

In what areas is the index.vuh you will add to File Storage different from the one I recently added under /view/ as a complement to the original one under /download/, and which is currently in 5.0 HEAD?

(The index.vuh file I added under /view/ is an almost exact copy of the "CR-generic" one under /acs-content-repository/ which uses a fixed version of "content::init" which enables "pretty URLs" and an easy way to template content items/types in general)

/Ola

Ola,

Oh, I'll look at that. Why is in under /view?

That just again abstracts the problem. The files should have always been exposed as suchL
/file-storage/foldername/filename

I'll look at your code, and probably move it into the package pageroot. I can't see any reason to have to add a special /view element to the URL.

Hmmm.

I see, you can't have an index.tcl with an index.xql and an index.vuh with a different index.xql.

That is a small problem.

What is the difference between view and download?

My main goal was to get rid of the download directory.

Besides prettiness, stable URLs are one of the most requested features.

I think I finally see what you want to do, Dave.

You will merge the "folder chunk" (index page) and the /view/index.vuh functionality into one index.vuh and put it under /, right? That would be brilliant!

It should probably be easy to make content::init "return" any version of a file, not just the live one, if "?version_id=xxxx" was appended to the item's path (I don't think it works like that right now).

That way versions could be templated, too, and we could stop linking toward the /download (or /view) folder - both on the main page and on the "view details" page - and link to / instead.

Too bad this UI change won't make it in time for the 5.0 release (or will it?) ...

/Ola

Don,

Is there an application that publishes content-repository content, so that I can see this in action? I'll install the CMS if that's the only way to do it.

Also -- I understand the idea of merging content with templates, but why is that necessary? The ACS-templating docs tell me that templating doesn't require the database at all. So you can publish the content directly and still get templating, without the database hit. It seems to me much preferable to get the content directly, perhaps with its metadata in an accompanying XML file.

Take care,
Shawn

Discussion of publishing content to the filesystem moved to https://openacs.org/forums/message-view?message_id=138570

Claudio, in case you hadn't seen it, there has been more XML-RPC and/or SOAP work going on lately. At least Vinod's XML-RPC package will eventually become part of the OpenACS toolkit proper, I bet.

Hi Tammy, let me make a few annotations to your requests:

• OpenACS in-a-box install: Björn Kiesbye has been working on a Knoppix CD running OpenACS. This should be helpful for testing it out. I'm no utterly aware if it is easily possible to install this, but yes, why not.
• Someone made .deb files for 3.2.5. Is there any chance, we could get them for OpenACS 5.0 / .LRN 2.0 / AOLserver 4? (Read: Would the one having done them be willing to make it again)
• Upgrade processes are a big thing for the new release as a lot of sites have to deal with this problem. Always keep in mind though, that you won't be able to upgrade easily if you made custom ammendments.
• aD Bootcamps: Azri ran one internally in India, a bunch of people are talking about having one run in Germany early next year. Once we are a little bit clearer, I'll make an announcement. I utterly agree with you there and it is on my agenda as part of the ongoing process to promote OpenACS to developers.
• I use AOLserver4 without problems. I created yet another installation instruction (for OS X, that works 100% the same under Linux) which I'm not putting up on the web as of now, but will discuss with the maintainers of the official document to get my ammendments in there. It is using AOLserver 4 (out of CVS) and has no problems with tDOM (package require and such). Kudos to Vinod for the tip.
• At Azri we have been thinking about asking senior developers for mentoring on pro-bono work for OpenACS. Basic idea would be to put a "more than worker bee" task up, find a newbie interested in doing it and guiding him/her on his task, check the CVS commit logs, be available for questions, stuff like that. For obvious reasons, it is not an easy thing to do, as most of the experienced developers are already swamped with client work.... And yes, the order could be changed (Newbie looks for senior developer for his idea on how to improve the toolkit).

Malte,

There's another thread (https://openacs.org/forums/message-view?message_id=135723) where I proposed the collection of AS4 installation notes. I think that's an appropriate place to post your docs for now. Would you mind?

Randy

Priorities

OK; Here is my opinion :- Maybe I am being tough but just accept it as "tough love". First of all most people are not coders and many people who may be interested in what OpenAcs has to offer have never wrote compiled a line of code in there life.

New Install HELL

As someone newish to OpenACS, I say it is very very tough to get from a bare bones system to running web services.

For OpenACS to succeed it is critcal to build up a critcal mass of users/developers, I guess too many new people give u saying "Yes it looks good, yes it nice, but I couldn't compile it, so I am now using mySQL and php". I took me 2 nights to work thru all the problems. You need an installer application that can get a Linux system from zero to running by a person who doesnt have a clue about the tools of a developer, Make, emacs and error.h files. It was no problem for me to get a php,postgres, apache system up running...yes I know this is comparing apples to oranges, but it was no problem, openacs fails because the newbie "get it going" hurdle is set too high.

Post Install "Where do I go from here", "how does that work" Confusion

After installation you should have "standard" web site showing off the great features the OpenAcs. I would prefer start with a fully installed system of all standard packages, then tailor them to my sites requirements. Gosh I shouldn't need to be looking at code to work out how to get the "FAQ" to work.

Finally I cannot help with this work as I dont know enough to be productive. But if the forum whish can retask a PC server (1GB*1GHZ*80GB) connected to 24*7 100MB/sec internet link to this work to develop such a "running start" openacs standard site.

BTW any comercial companies using OpenACS, could they offer a bug kill "bounty" system to time rich, money poor home developers/students from 3rd world countries like Australia to kill the bugs holding OpenACS 5 back? Kill a bug get $50, build functionally y get $100?

Hi everybody,

As a newbie - I think one aspect is most important for a growing and vivid community:

- a good documentation for admins, users, developers

And this is what OpenACS really needs to meet different groups and expectations. The first (for admins) to make OpenACS competitive with other platforms , that last (developers) to have enough contributors and maintainers for the platform. My suggestion is to have a steadily increasing Coding Best Practice Repository with lots of little articles on how to do this and that. This could be a starting point for folks who want to participate.

We could create such a repository by first consolidating existing contributions of  Philipp Greenspan, Joel Aufrecht, Reuven Lerner, Jade Rubick and the many others (if they are willing to contribute). Everybody should be able to post some little code on how to achieve something.

What do you think?

Greetings,
Nima

I can't agree more with Nima. If I have to choose _one thing_ that is absolutely important for OpenACS, it is good documentation. As a guy who programmed in Java before, I feel terribly frustrated that I can't find the right documentation for the problem I want to solve in oacs. Any serious open-source effort _needs_ to be well documented. As a person who is more comfortable with learning things by myself, I find it uncomfortable that I have to ask my senior colleagues for every small thing that I want to do. This has to change. If oacs has to be seen as 'developer-friendly', more tutorials, more thorough documentation has to be in place. I know it's asking for a lot, but if OpenACS needs to be taken seriously, I guess there is no other option.

Regards,
Vamsee.

Oops. I see Jade answered above. I look forward to sharing my drafts on openacs.org, too.

I would like to add some thoughts that IMO are important to make dotLRN the leading open source learning management system (plus the reasons):

• Easy installer for linux distributions like SuSE. I don't think RedHat is interested but now that Novel and SuSE merged SuSE will become very strong not only in Europe but also in the US.
• A SCORM Runtime Environment (1.2 or even better 1.3). As a good starting point we could go with the client-side libraries shipped out with the ADLNet SampleRTE if licensing allows this approach. Thus the API adapter on the server-side has to be reimplemented in OpenACS.
• An extended/improved gatekeeper module for integrating external web-based applications like: SquirrelMail, Horde-IMP, Wiki, University Libraries or any other service that uses the same user accounts. The gatekeeper should be able to produce valid html/xhtml, forward session and cookie info, check if source is compressed data or not, allow usage of master-template (this feature already exists), a better rewrite proc, keep a registry for single-sign-on feature...
  
  This package is a small but powerful feature due to it's integration qualities. I tested it with different sites from static html to php-based applications. It works even with frames. Now - this is very interesting - when I tried to spread the news about dotLRN at our university the number one question was: Can we easily integrate our web stuff and make use of the dotLRN access control and packages. The answer: yes! Run a local apache+PHP+mysql installation with the AOLServer as its only client and voilá.
• A wiki based documentation system for users, developers and administrators - complete and open to registered users with version control. There are many valuable info scattered in the forum threads which could be aggregated in wiki pages. We could either create our own package or integrate with existing. c't 25 from 1st. Dec. 2003 made an excellent comparison of available wikis:
  1. MediaWiki (PHP-MySQL) - 68,65 % >20 languages, no CamelCase, very strong in scalability and usability, weak in documentation, relatively easy to install
  2. MoinMoin (Python-Text) - 1,75 % 8 languages, CamelCase, very strong in documentation and usability, weak in scalabilty
  3. PhpWiki (PHP, GDBM, MySQL, PostgreSQL...) - 1,59 % 7 languages, CamelCase, weak in documentation, strong in backend binding
  4. Twiki (Perl, RCS) - 4,49 % English only, CamelCase, very strong in documentation and plugins, weak in usability and scalability, most popular for intranets
  5. UseModWiki (Perl, proprietary format) - 16,32 % 18 languages, average, extremely easy installer
• Migration to latest AOLServer and PostgreSQL
• A consistent UI. There are UI changes (package-2-package) and (package-2-core). Also if we want to make use of the gatekeeper module with a master-template we need to have a unique CSS. Otherwise external designs will mess ours up. I tried it and it's a mess.
• Extended File Storage module so that the administrator can decide between the options to store files into database of with OpenAFS. Advantage: User can access and share owned files over IMAP, SSH and other usefull services.

Merry X-mas and happy new year,
Nima Mazloumi