Forum OpenACS Development: Response to Edit This Page 2.0 project
I like the idea of distributing ETP apps as packages. The concept of symlinking into the ETP package on install makes me cringe a little bit, though. A few reasons:
1. A secured ACS installation might not allow nsadmin write access to the tree in a production environment, so the install would be hairy.
2. Symlinks are a very platform-specific thing, though it is looking like OpenACS and UNIX are pretty well joined at the hip anyway
3. Symlinks being created by packages would probably be something of an administration hassle for anybody keeping their ACS tree under version control.
How else can we hook up these pages? First a little bit of ACS historical perspective. (note: this is about to go way OT, and is obviously not something that can make it into this release cycle)
ACS/OpenACS <=3.x always had a convention of using web pages as API. This made things like /general-comments possible. When developers at aD sought to actually build apps for 4.x, they were shocked and disgusted that there were no guarantees that ANY canonical location existed for a given page. In fact, a debate raged about whether a canonical location should have been established for every package to clear up this problem. But that would have been wrong as well (at least as "correct" usage of the toolkit has evolved), as usually, multiple instances of the same application are peers; seperate but equal, and no instance could presume responsibility over the others.
What we need, then, is a system to globally mount utility API. Maybe this would take the form of a package subdir named "www-util" that gets mounted under "http://server.name/util/package_key/" upon installation of the APM. Maybe it means adding a flag to ad_proc to actually provide public web procedures referenced like: "http://server.name/web-proc?proc_name=foo&arg1=bar&arg2=baz". The latter approach could even eventually lead to the integration of ad_page_contract and ad_proc, which as they exist currently are eerily similar, but different.
I know that aDers have had to use some very convoluted techniques to traverse the site map in order to find the location of another package mount point that is an acceptable provider of whatever URL-API they need. I haven't looked at the code, but I know that Phong had to do some ranglin' to port the general-comments module, as he pretty much had to invent the technique he used on his own.
Some would propose that singleton packages solved this problem. This would really only be true if 1. singleton packages were always mounted at a set URL (not possible for non-core packages because of potential namespace conflicts with a given user's ACS install) 2. You shouldn't actually have to mount a package in order to use its API, because that's what this is... even if it comes up in somebody's browser window instead of getting called behind the scenes.
Enough of that... too much thinking about reengineering the core will make your brain melt (cough..ACS5). Back to the topic at hand...
I'm interested to know what kind of perms would be used by the ETP2 system. I have the feeling that a complex workflow with many actors will require a more elaborate permissions model than a single admin privilege on a given ETP instance. At the very least, creating, editing and publishing content seem to be different tasks that could be delegated to different actual parties. Not to mention the possibility that some actors may only have control over an object while the object is in a certain state or set of states. I'm not saying that this isn't in the works already, It just wasn't clear to me how it was going to work from the document. For all I know, acs-workflow handles this already, or maybe the whole workflow goes on behind the permission model's back, which may be the Right Thing after all... haven't done enough thinking.
Otherwise, looks great to me. All of my gripes with ETP1 seem to have been cleared up. Now I'll just have to port all of the hacking we did to get around its limitations to ETP2 :)
-John
