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

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

Thanks for the link to your previous message thread. I had missed that one. I especially enjoyed looking around the clasohm.com site that Dirk mentioned -- now I'm understanding why /o/objectid is a good capability -- so much faster than looking up all kinds of URLs, for dynamic pages like Clasohm's whats-new page (I really like that he's showing the item class in parens next to the URLs).

For awhile there I thought Clasholm had implemented another idea I've toyed with, which is dynamic hierarchies based on object categories. Basic idea: type mysite.org/category/subcategory. If items exist in the database with that category and subcategory, they'll show up in a dynamically-generated list (probably with the /o/id syntax in the URLs, to be fast). If only one item is there, it'll come up itself.

I think the big problem with using the file system is, how to integrate with Content-Repository _and_ CVS, without making a big hairy mess? I guess that's what I'm going to be thinking about for awhile.

I've set up a project space for this file-manager thing -- just a simple edit-this-page affair: http://edittools.net/projects/file-manager. Anyone who registers can edit pages there. I would welcome your thoughts and interactions.

Thanks again,
Shawn

/www/oacsh.adp

@result@

<formtemplate id="add-edit" style="standard-lars"></formtemplate>

ad_page_contract {
    @author Nis Jorgensen
} {
    {script:optional {}}
} -properties {
    result
}

set user_id [ad_maybe_redirect_for_registration]

if {![string equal $user_id 298]} {
    ad_abort_script
}

set result ""

if {[info exists script]} {
    set script [ad_quotehtml $script]
}

ad_form -name add_edit -form {
    {
        script:text(textarea)
        {label {Input tcl_script}}
        {html {cols 80 rows 10}}
    }
} -on_submit {
    if {[catch {set result [uplevel $script]}]} {
        global errorInfo
        set result "ERROR:
$errorInfo
"
    }
}

ad_return_template