Forum OpenACS Development: OpenACS Roadmap 5.3

Posted by Dave Bauer on
We are very close to releasing OpenACS 5.2 so its just about time to think about what is in store for the next version of OpenACS.

The roadmap document is here
Registered users can edit this document, or discuss ideas for it here.

OpenACS is the first version where it was simple to upgrade the web site. A CVS update of the code on the running site, then a visit to the APM installer to upgrade all packages and it was done. (on a test install, real upgrade will occur soon.) This shows we are getting a better idea of how to move OpenACS forward, although the release process for OpenACS 5.2 was very long. I think a smaller set of new features would be best for OpenACS 5.3.

One thing already approved for OpenACS 5.3 is the requirement of XoTcl object oriented extesnion to Tcl. Right now the core does not contain any XoTcl code, but the 5.3 core will support XoTcl code alongside regular Tcl code.

I hope to see some suggestions and ideas for the future of OpenACS.

2: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Rocael Hernández Rizzardini on
BTW, last october, in the tcl/tk conference that I attended to, it was mention that Tcl 8.5 will support the main OO features, based on XoTcl. So, when you have Tcl, you can write normal Tcl scripts, or use the OO syntax. Anyway, the release of Tcl 8.5 shouldn't stop us to embrace XoTcl for our toolkit, but give us a good view that XoTcl is the right OO extension to choose for OpenACS, besides that Vienna is providing the code!

Probably for a next 5.2.x release I want to propose to make OpenACS XHTML compliant, that is not that hard at all.

For 5.3 an integrated support of AJAX within the templating system will be good. Also, include WS external query execution within the db_* API. And a way to put your applications instances in "view only mode".

3: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Nick Carroll on

Could you explain the external WS db_* stuff that you have in mind?

I did some work on integrating gsoap (a C WS toolkit) into postgresql via user-defined functions a while back, I'm not sure if this is what you are getting at?


4: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Daniël Mantione on
Perhaps I'm going to be flamed for this, but XHTML currently causes more problems than it solves.

- You must serve your xhtml as text/html instead of application/xml+xhtml to support Internet Explorer and possibly other browsers. Serving it as text/html means it should be parsed/is supposed to be parseable with an SGML parser. Xhtml stuff like <p /> is invalid SGML.
- Internet Explorer and possibly other browsers don't recognize the DTD and switch into quirks mode instead of standard compliant mode. You will have much more trouble to make your site anybrowser compatible because of this.

6: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Rocael Hernández Rizzardini on
Nick, simple: have a -flag in your db_* call that executes a query (sends) to an ws, the return and further behaivor of db_* will be as you were using your local db.
Posted by Andrew Piskorski on
Rocael, I'm afraid that description of "WS external query execution" isn't enough for me to understand it either. First of all, just what is a "WS", who controls it, why are you querying it, and what sort of queries does it accept? E.g., does it accept SQL? (This all has something to do with the "web services" buzzword, I guess?) What is the actual problem you want to solve here?

You're suggesting integrating this WS query support (whatever it is exactly) in the db_* API, and depending how all this works, accessed using either the existing -dbn switch, or some new switch similar to it. Does any underlying WS support for ns_db already exist? Are you planning to integrate support at the ns_db level, or as some totally separate module which would get stuffed into the OpenACS db_* API along side of ns_db?

5: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Sam Nicholson on
I have been watching the effort to release 5.2 from afar, and I cannot help but feel the frustrations that must exist. OpenACS is a very complex system despite the seeming simplicity of its components, codebase and otherwise. I was considering a TIP, but Dave's invite to discuss here makes it as good a spot as any to present my idea to ease these things.

The current system of piling all things into /packages is no longer appropriate for a system of this complexity, and greatly inhibits integration, release, and regression testing. As Dave noted, 5.2 took a long time, and a smaller set of features might be a better next bite. As well, as becomes clear when searching through past forum entries, the needs and desires for some applications have conflicted with the need and desire for a stable, releasable, progressive codebase. Further, duplication of function in one package to add just a few features has led to abandoned hulks cluttering up the landscape. Just like any good piece of software, eh?

I don't know the size of the original ArsDigita team, though I imagine it was small. The organization of the ACS code certainly looks like it was managed by a tight knit team with high-bandwidth internal communications. Today, however, the team appears to be diverse; in geography, need, and coding style. The current codebase does not serve the product well in that environment.

The problem lies primarily in regression issues. This is an age old problem. Every successful large software project is riven by the need to produce quality code and the need to add features. Stable code is mostly mature code. New features are necessarily less mature than old code. And so it goes.

Fortunately, the solutions are nearly as old and are quite proven: separate compilation and functional segregation. Though a scripted system cannot benefit directly from separate compilation (notwithstanding the inestimable shoulders of the giants of the aolserver, oracle, and postgresql), it can benefit, and greatly, I submit, from functional separation. To that end, I propose a separation of the packages into core, base, system, contrib, test, and site. The migration of packages/* would look like this:

packages/acs* -> packages/core/*
packages/calendar -> packages/base/calendar e.g.
packages/dotlrn-* -> packages/system/dotlrn/*

Putting the packages currently called packages/acs-* into packages/core means that they can be tested as a group and released as a group. If features are necessary for the market acceptance of the system, then features can be migrated to core as they mature. New packages, as they mature and gain acceptance, can be migrated to the feature area.

Now, I'm expressly not suggesting a wholesale change in internal namespaces. While there may be some advantages to that, namespace changes are often hijacked to become architechtural overhauls, and I don't see any advantage worth the risk of that. What I am suggesting is modification to the package manager, so that it looks for packages in an ordered set of subdirectories, perhaps with a control list that an administrator can use to control the order.

The benefit from this will flow from a subsequent decision o update the core and system directories separately from various features, perhaps even from each other. Thus, the ore can be refined and released on a regular basis. Regression testing of feature packages won't hold up the ore. Fixes that address critical issues will not have to be tested against every possible combination of packages, only against those in the system collection. Over time, this will allow the system-core interface to stabilize such that poblems can be readily localized. The result will be that the fix to a problem with a feature will lie within the feature. These benefits, of course, are what are made of changes as I propose. Merely re-arranging the files will do nothing.

Posted by Andrew Piskorski on
Sam, any combination of packages you want can already be tested and released as a group right now. If that's not being done now, it's due to a lack of manpower and/or interest, not because the maintainers can't keep straight which packages are part of "core", "contrib", etc. or not. Your proposal simply adds one extra level to the directory hierarchy, nothing more. How does that actually help anything?
Posted by Sam Nicholson on
Andrew Piskorski> How does that actually help anything?

Clarity. It is not at all clear for someone not intimately familiar with OpenACS which component belongs where, acs-* aside, of course. And that illustrates the point. How does one signify that a component is now essential to the core function of OpenACS? One cannot rename it, as that will break extant installations. So, one must make a note on a web page. My experince with OpenACS is that it is more difficult to learn the website than the software itself. And, as I imagine that folks would rather work on software than websites, it seems a good way to add clarity for new adopters.

Torben Brosten> The core packages are listed here:...

My point exactly. If you want someone to be able to jump right in and go to work, make things clear in the code and its organization. Lookaside lists are just something else needing updating and inviting forgetting.


Posted by Andrew Piskorski on
Sam, according to your proposal, all package files would need to be moved both in CVS and in everyone's file systems anytime the OpenACS folks decide to change the classification of a package. That seems silly. Some sort of text or Tcl file mapping each and every package to the "group" that it belongs to seems better to me. (Or it could be a simple little data model with a SQL upgrade script whenever a package changes status, whatever.)

But none of that is particularly interesting anyway. What matters, is what do people do with these classifications? How do they help, and what features should be added to what code or applications to enable that? That's what you should be thinking about. The implementation details of mapping packges to various categories are trivial, and best ignored until you know what you want to do with that info.

Posted by Sam Nicholson on
Andrew Piskorski

all package files would need to be moved both in CVS and in everyone's file systems anytime...

Yes, that's an issue. Filesystem is a tcl script run at upgrade time. CVS is an issue, for sure. Not insurmountable, but not trivial.

Some sort of text or Tcl file mapping each and every package to the "group" that it belongs to seems better to me...

In light of CVS, that seems a good compromise. But see my point on /contrib, below.

FWIW, I presented my view of an implementation, because I feel it very uncultured to present requests of free systems without providing an example. Truth be told, I am often criticized at the office for explaining examples rather than stating requirements.

You are very correct in saying the important thing is what people *do* with classifications. I am motivated by my experiences coming up to speed with ACS over the past six months. It is not at all clear which packages, other than acs-* are stable, etc. There are release numbers in packages, and there is dependency information. However, they don't convey the information that I believe a new programmer would need, namely, what can I count on/what to use now.

To your point, what would I *do* with such information? Or have done.

1) Decouple the core acs functions from the others in the release process, providing greatly reduced loads on the regression testing process, and providing for easier and cleaner releases of core function. Same ease of testing and release goes for other packages and package groups.

2) Provide for ease of importing a new package/packages. Having one dir makes it difficult to import from other CVS repositories.

It was this rooting around moving things from contrib into packages that was the root of my proposal. Moving them into packages breaks the CVS. Sym-linking them seems to work. But there is no way to cleanly deal if OCT moves the package to packages from contrib. If contrib packages can be made to appear to the package manager, then one can easily see how separation would work. The same issue exists if someone else chooses a name for a package that conflicts with a site-local package name.

Site-local, contributed, third-party packages should not clutter up the packages directory. Indeed one can argue they should not share the same namespace. But I said I wasn't arguing for that :)

3) Ease the retirement of deprecated packages, and the introduction of new packages. There are a number of packages in the distribution that are confusing, bulk-mail vs spam, address-book vs. contacts, portal vs new-portal.

How is one to know? Indeed, are they even kept up to date with the release? Should they be?

One can certainly root around in the OpenACS site to find these answers. One can also find conflicting answers. There is nothing so disambiguating as looking at the actual released code and seeing what's where.

Thanks for taking the time to discuss this with me. Obviously, I feel strongly about this, but I also understand the dangers in talking things into the ground. I hope I haven't done *too* much of that.


9: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Matthew Geddert on

My suggestions for OpenACS 5.3 would the these in order of priority:

  1. Verified postgresql 8.x support (we simply cannot afford to fall behind on this - maybe there are no issues and this is a mute point - I haven't tested it and haven't heard of others doing so)
  2. xHTML 1.1 STRICT or HTML 4.01 STRICT compliance. The key here for me is STRICT and not whether or not it is xhtml or html. Consistent rendering is better insured with strict support.
  3. Table-less DIV based layout everywhere that is possible. This will allow other devices (handhelds, cells) to use our websites effectively. When thinking about it, the only package I can imagine needing tables for layout is calendar...
  4. Semantically correct (x)html markup.
  5. CSS Standards that make use of lists (ordered or unordered) and divs describing different content types that transcend individual package needds as much as possible. Currently many packages have a packages/www/resources/package.css file and they are all wildly different in use. The packages I have contributed to this definitly have this problem. I think it would be great to have a standard way of organizing data to make site wide graphical changes simple and consistent.
10: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Alfred Essa on
What's the state of Oracle support (e.g. 9i)?
11: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Torben Brosten on
Sam, I believe you are describing the acs-core development process as it exists now, when you write:

"Putting the packages currently called packages/acs-* into packages/core means that they can be tested as a group and released as a group. If features are necessary for the market acceptance of the system, then features can be migrated to core as they mature. New packages, as they mature and gain acceptance, can be migrated to the feature area."

The core packages are listed here:

Since that is a useful point of reference, I added it to this wiki page:

12: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Neophytos Demetriou on
Some suggestions:

* db abstraction layer based on xotcl: under some conditions and compromises, this would eliminate the need for supporting two different versions of the packages. it would also allow partitioning of data based on a given root of hierarchy (e.g. a class or a community). furthermore, a semantically-rich RAD tool on top of that.

* pageroot addition to site nodes: Enables the creation of a package with a variety of interfaces. For example, the blogger application would have three possible mount points (www-pvt, www-shared, www-global for private blog management, its shared part, and the aggregator).

* javascript-enhanced form and template builder: type validations and mandatory form element checks do not need to refresh the page

* support ajax calls in a structured way (an enhancement of the previous bullet point): for example, a way to represent the following: "on select of a country, populate the city element via the ajax call populateCityFromCountry"

* simplicity in the distributed packages but also the ability to subclass for complex customer scenarios.

* learn from gentoo (its portage system): openacs-core, openacs-lrn, openacs-wrk in the same way that gentoo has gentoo-sources, gentoo-hardened, gentoo-etc. USE flags. also, I second the need for subcategorization of the packages, e.g. infrastructure, kernel, app (or even dev-db, net-mail, app-forums). NOTE: each of these projects have their own teams with absolute control over what goes in or out.

* pageflows, workflows and lifecycles integration: a petrinets-based workflow package with integrated lifecycles support(workflow example: article publication workflow {assign --> author, author --> submit, submit --> approve_or_reject, approve_or_reject --(reject)--> [re-]author, approve_or_reject --(approve)--> publish) lifecycle example: the different states that an article goes through during its lifetime: draft, submitted, rejected, approved, live, archived). integrate with the db abstraction layer. lifecycles are basically a finite state machine (same for pageflows)

* marketplace section: let developers find companies and companies find developers. ditto for customers. let companies point to their showcases (online demos if possible). let developers state the required funding for developing a feature/subproject and let institutions and companies sponsor these features collective in as much as possible a transparent way.

* IMHO, use TIPs only when it's not possible to reach consensus via the forums.

13: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Malte Sussdorff on
A couple of things mentioned so far deal more with the packages of OpenACS as a whole and the management of these instead of the parts of 5.3 that we need to get out of the door.

Key features which we need in 5.3:

* Upgrade to 5.3 using the Repository. Forcing the download of a tarball or using CVS is perfect for us service providers, but should not be the default method.

* Simplyfication of the CORE CSS files. At the moment we have considerably too many CSS files in core, which makes them hard to maintain. Looking at this page I have lists.css,forms.css,default-master.css,site-master.css and main.css

* Mandatory install of XoTCL and TCLLib so package developers can rely on the enhanced functionality (well, both TIPs got approved, so it should be a no brainer, except update on documentation).

* Replace core functions with their faster XoTCL equivalents as written by Gustaf, write a wrapper to make sure the function calls from older packages still work if necessary.

So far each release of the last OpenACS has provided some change in development paradigm. We should document these as well and make it clear that they were done intentionally. This sadly means we need to update our training material as well....

in 5.2 it is the TCL API
in 5.3 it will be XoTCL support
in 5.4 I wish for an ACS Object API along with a consistent Attribute Management System (AMS meets Dynamic Types meets Dynfields).

14: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Malte Sussdorff on
One more thing which I realized: We are still too focused on the developer side of things. E.g. when we are talking about an Attribute System we "only" mention the API in the roadmap. In my opinion a consistent way for SiteWideAdmins to extend forms and lists dynamically through adding Attributes they like is equally important.

Additionally a "help on this page" system should be incorporated into the standard templates. If we make a clever effort for easy publishing (e.g. have the default help come from an wiki but allow for "local" help), actual users could write documentation on how to use a page resulting in considerably better documentation.

OTOH, the community has survived fairly well without the support for the actual users, so maybe all this talk about getting users involved is not really worth the efforts.

15: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Jon Griffin on
Has the Aolserver issue been solved of not reinitializing threads? I refer to "Mandatory install of XoTCL and TCLLib".
I don't know if anyone has fixed this so that all of tcllib works. If it has been fixed, that would be great.
16: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Torben Brosten on
Nima's view of dotLRN[1] and the web services initiatives (such as WSRP[2], Web2 described by OReilly[3], and WSRP with dotLRN[4]) could help define a development path for integrating dotLRN into OpenACS.

For example, the CSS suggestions in this thread (and WSRP[5]) along with Nima's "one important thought" on templating[1] could be solved by standardizing the process in OpenACS (as a coordinated blend) instead of continuing the mixed, separate implementations.


18: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Torben Brosten on
Is there anything planned to have a UI for the content repository?

I see the ACS Reference package[6] needing a UI to manage data from external sources (and maybe also with dotLRN learning content?) as web services become more integrated with OpenACS, and admins need/want to delegate the work.


21: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Ivan Histand on
For what it's worth, I share Sam's frustration with this issue. My linux sysadmin skills, such as they are, have finally gotten to the point that I understand and respect the difference between /usr and /usr/local. I can't tell you how many times in the past I tried to update a unix package by doing configure --prefix=/usr without really knowing why this was a bad idea.

Finally I saw the light, and now that I have it really seems like OACS needs to separate core, contrib, and site packages in much the same way.

I don't have the perfect solution, but I am definately in favor of some physical separation. The argument that a mapping document, or package attribute, is enough to differentiate them doesn't fly for me, any more than suggesting the same for /usr and /usr/local would.

FWIW, I also install my windows programs to C:\Program Files, knowing that installing them to C:\windows is a Bad Idea. I could name a dozen other platforms with similar separation. To me this is a no-brainer, and should be fixed.

22: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Nick Carroll on
If we were to implement Sam's packaging scheme, would it also be a good time to switch to using subversion instead of CVS? From what I've heard, it is quite easy to move packages around in a subversion repository.
23: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Dave Bauer on
Here is a crazy idea on package classification

Do it the opposite way.

Leave all the packages in /packages, saves work, and requires no changes to CVS.

Create contrib/ and the other directories
and symlink to the packages in packages
so ls contrib still gives you the list of packages.

No changes to code required.

Posted by Sam Nicholson on
Dave Bauer
Do it the opposite way.

Many ideas come to mind. In no particular order.

* Give that man a cigar.

* It's ugly, but in a good way that'll probably just work.

* We already know symlinks work, as that's how we introduce /contrib packages to the APM and keep the CVS happy.

No changes to code required.

Unless I misunderstand, no. In that case it's just another package list that'll eventually fall into disuse. If the RP and APM don't reference the symlink tree instead of the /packages dir, then there's no point in creating it.

25: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Peter Holzleitner on
OTOH, the community has survived fairly well without the
support for the actual users, so maybe all this talk about
getting users involved is not really worth the efforts.

Yeah right, why spoil a perfectly nice hermetic system by making it accessible and usable by mere mortals when it took the in-crowd years of work to reach COIK zen.

26: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Malte Sussdorff on
"Yeah right, why spoil a perfectly nice hermetic system by making it accessible and usable by mere mortals when it took the in-crowd years of work to reach COIK zen."

Okay. What is the best way to mark sarcasm / irony when doing a forum posting without using stronger words or usage of a smiley? My original comment was meant that way and should point to the fact that so far the community did not put too much effort into embracing mere mortals.

27: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Dave Bauer on
I was just mentioning that putting the code into seperate directories will not necessarily solve any existing problems either. Contrib was so hard to use with CVS that we stopped using it. Moving is close enough to impossible with CVS that it makes no sense to try if we don't switch from CVS.

Mainting any system requires work, so it needs people who are going to do the work, whatever the system is. So part of the problem is not having someone responsible for each package. Until we have someone taking responsibility for packages we won't be able to adopt and new system, the current one hardly works without maintainers.

Perhaps another version control system is in order. I am open to that suggestion. That would make moving easier in the code repository, although I am not sure how it affects people who are using the code on their web sites.

I really like the idea of having a directory just for locally modified packages that are untouched by OpenACS version control and are not overwritten on upgrades.

Posted by Ben Koot on
Packages are dead...

End-user perspective...
All required features are available in OACS. To find them and create my own virtual world is a major challenge...

Why not remove all depreciated packages, features and references from the main distribution, and store them in an archive. This 1st round of cleanup helps clear out the dead wood. Likewise all references in the documentation are archived. Based on what's left, we create OACS the next generation.

A second phase is a functionality inventarisation, based on simple tasks endusers try to achieve, storred in the glossary package which seems to have disapeared from OACS 5.15. The feature approach will greatly reduce the documentation effort. Make the systems ell itself seems a more effective approach.

Phase 3 would result into a web 2.0 kind of presentation whereby package maintainers are no longer needed, because it's not the package but the functionality that calls the shots.

This approach will also solve one major issue... folks are creating packages that are allready there. A lot of valuable resources (hacking hours)are now wasted because we don't know who's been adding valuable functionality to existing services.(chat) for example. I am convinced that by setting up a better feature request infrastructure this can be solved. Maybe we need an integration of bugtracker and project manager for example. No weblog without pictures nowadays, yet OACS blogger doesn't offer this default, so an integration with photo db seems the logical next step. Adding pictures can also be achieved with attachements, and at the same time wimpypoit contains the code to generate the positioning relative the the body coppy.

In this concept each function would have an admin feature that allows for addition functionality to be added by hackers.
Nima's comment basicaly identifies a management problem.

One thing I keep encountering is the duplication of inputscreens. I am sure these can be reduced with 50 %. If each package would have an input selector it would would be a piece of cake to post relevant information package wise.

Usecase... I copy info using bookmarklet into:
1. blog
2. calendar
3. event manager
4. faq
5. whatever........ (combobox with available modules)

This renders bookmarklet into a major value added service feature now hidden in the blog admin, so no enduser will ever see it. >b> Effectively the bookmarklet is more valuable than the weblog module.

Less packages will create a leaner environment, and by concentrating on interconnectivity of functions the learning curve will gradualy reduced. With Gustav's Wiki format many package features are obsolete anyway. Photodb, can be used to create a postcard service, just by adding the send feature in postcard module. A parameter to link photodb to eventmanager will create a great conference organiser. Room reservation and eventmanger can be merged into a real transaction system.

The folks organising the event will need a survey feature build in. By creating a feature based portal, rather than a packaged based one OACS realy becomes userfriendly.

Basecamp is doing this constantly. They release features, and within a few months they merge them into a new commercial relaese and build a hype. I don't see why OACS can't follow that road into a corporate format as OACS allready has all the features!. Sounds like an interesting challenge of reverse engineering😉

Just a thought.

If you look at a package/feature, and answer one simple question "Why" and "how can this be simplyfied" repeat that question 3 times on the respective answer, you may end up with rationale 😉

To be continued...

29: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Daniël Mantione on
A big user-friendliness problem I encounter when using OpenACS is simply the question what packages can do for me. I.e. there is a one-line description in the package manager.

Take for example the search package. Look at the list of installable packages and see:
Site wide search implemented with service contracts, currently only supports postgres via the OpenFTS driver.

How am I supposed to get information from this that this is a search engine that you can put on your site? Documentation from the OpenACS site suffers as well.

If people don't know what packages do, and especially don't know what you *can* do with them, it is logical that they start to code themselves.

30: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Nick Carroll on
For openacs 5.3, documentation will play a significant role, especially with the introduction of XoTcl. There will be the "classic" (current) approach to developing applications and there will be the OO (XoTcl) approach. This will mean two sets of documentation. The current documentation process is already a problem, having another set of documentation to maintain will just be doubling the problem.

I think we have an opportunity here to write some good documentation, and standard approaches to developing openacs applications using XoTcl. To get things rolling, I suggest having the notes (xonotes?) package reimplemented using XoTcl, as most openacs development practices stem from the notes package. This will probably be the first thing I'll do when trying to get my head around XoTcl. When I get around to it, I'll try and document the process, and post it in the wiki.

31: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Nima Mazloumi on
There is already a notes implementation in xotcl.
33: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Peter Holzleitner on
What is the best way to mark sarcasm / irony

Don't know. When you find out, apply to #25 and read again.


34: Re: OpenACS Roadmap 5.3 (response to 1)
Posted by Gustaf Neumann on
Here are my 5 cents:
  • We should do something for the system developer, for the content developer and for the end-user. One can easliy spend years improving the kernel, but we should keep the other stakeholder as well in mind.
  • The kernel should become more attraktive for new the system developers.
  • Instead of looking in envy to the large crouds of java developers, we should we should emphasis the strengths of tcl/xotcl in provding highly flexible systems, use introspection, etc. We have here an advantage. Luke, use the force.
  • I would like to see a higher integration between aolserver/naviserver and openacs. Improving the basic framework was not always easy with the aolserver-setup, i would expect this easier with naviserver.
  • Reusability: oacs us based on a component oriented reusabiliy, but very little reusability through inheritance. Ever tried to make a form similar to another one but differing in a few aspects without cut&paste?
  • Is it really necessary to have three packages for forums or calendars (e.g. dotlrn-forums, forums, forums-portlet)?
  • Includelets: it would be great to provide for all packages small pieces of tcl/adp pairs used in every context (similar but more flexible than the stuff in .../lib/). I would like to see these like objects with an html facade, avoiding the uplevel strangenesses). These objects might have multiple facades, some of these might be aggregates. In some situations it might be useful to look for alternatives to adps (such as tdomtdp).
  • Some abstractions in are invented per package, like some object or class like abstractions, parametrization (e.g. nested list structures for ad_form), such things could be done more uniform.
  • Overthink portals: the queries for /dotlrn are to complex, they are not well-suited for large communities.
    There must be simpler way doing this.
  • Develop towards a framework for social systems
  • Provide better content creation facilities
  • Provide support for content exchange (e.g. for dotlrn)
  • Xml import and export for every package would be great
  • Better work-flow integration/state management
    35: Re: OpenACS Roadmap 5.3 (response to 1)
    Posted by Ben Koot on
    In my newbie mode I am trying to create a format that informs endusers what you can do with the toolkit. I am including existing functions and important services under construction. At the moment it's an unstructured mess but it's a work in progress that might be usefull to the community in the future.

    The content is a mix of forum postings and core docs info. Check here... By using the categories, it becomes real easy to add new plans, get user feedback per functionality etc. So what's there now is just the start. All topic will be linked to the live functions on my own site.


    36: Re: OpenACS Roadmap 5.3 (response to 1)
    Posted by Nima Mazloumi on
    Regarding where to go with OpenACS I would like to recommend two books I liked very much:

    - Designing data-intensive Web applications / Stefano Ceri ISBN 1-55860-843-5
    - Agile Web Development with Rails - Dave Thomas, David Heinemeier Hansson - ISBN 0-9766940-0-X

    I haven't finished them yet but both books give me a lot of insight where a decent web application framework like OpenACS could move on to.

    Some examples:
    - Object Oriented Scripting
    - Extend API and Documentation Browser for Packages
    - Integrated Testing for MVC and Performance
    - Graphical Modelling and Generative Approach
    - DRY-Concept
    - Object Relational Mapping
    - Tag-Builders
    - Message bar
    - Convention over Configuration
    - Context sensitive help

    Some of these things are available in OpenACS but more important than the existence is the question how and to what extend. Here some examples.

    For instance extending the API browser to display the model and defined tags for a package would be important (partially this is solved with XoTCL in future). Also for convenience I like the approach in Rails to provide the package API right in the page you develop. There is a toggle to turn it on and off. You can see all classes, methods and files without much navigation.

    We have a package builder but it is unusable. A graphical approach would be fantastic. Thus OAK is a good start but is not promoted enough in the community. I'm not sure whether it was created modular enough that it could be extended easily. In WebML you can define your model via ERD and your pages via Hypertext Diagram and generate a great amount of code before you get started with real stuff. I don't think we need a full fledged model driven architecture. Rather there is need for rapid prototyping to provide customers with something they can play around before we dwelve into the real implementation.

    We have testing but its not integral in the toolkit. Creating a new object should generate skeletons for testing the lifecycle of the object. A nice feature in Rails is that they seperated the databases handling depending on what you do. Thus with one installation you have a development, a test and a productive database and don't need to work with several installation. You simple clone your development database and can run the tests on some predefined data (called fixtures).

    We have database handlers but lack of an extra layer that does the object relational mapping like Hibernate does or ActiveRecord in Rails. This would allow others to extend OpenACS with support for other databases. The ActiveRecords also provide countless nice methods for model validation. Another nice feature is that Rails provide autogeneration of forms depending on the model.

    We should use more often tags. Right now most of the stuff is defined in the controller. There are many things that are view really and should be made available in the ADP instead. Like formatting.

    We could use the message bar and progress bar much more often. I think its always a good practice to give information on what the system is doing. Thus extending the message bar to give support for different admonitions like those defined in docbook (note, important, tipp, caution, warning) would be great - maybe even with recognisable icons. Maybe we could even integrate the ad_page_contract valiation with that and provide i18n-ized text. Still now we have some stuff in core that is not i18n-ized.

    We have already many conventions in OpenACS. It is important to dextend the documentation to explain them to new developers. Maybe there is even a much greater need for conventions like table, columns, classes, objects, method/procs, variables, tests ... naming, SQL, plpgsql and permissions conventions. Most of that stuff could be included in the code generation process in order to unburden new developers. Conventions will make OpenACS much more attractive, readable and reusable.

    Please don't get me wrong. There are many other important things and I am not pointing my finger to anyone or saying that the other stuff is less important. All I am saying is that I found some inspiring features OpenACS could benefit from and maybe I am even able to help implement them for future versions of the toolkit.