Forum OpenACS Development: A Wiki Page per Package?

Posted by Caroline Meeks on 12/27/05 01:41 AM

I am excited to see so many posts about how to improve openacs.org. I’ve been thinking about what to do first. I thought back to various classes and trainings I have been on things from process engineering to remediation to management... Step 1: Measure what you want to change.

So one question I have for everyone is what do you most want to change? What I gather is that people most want things to work and second, if its likely not to work to people want to know that easily.

We recently did a project with XOWiki which has the ability to use includes. It seems to me we already have a bunch of data about packages and we could use XOWiki and includes to pull some of that out onto a wiki page. Then use the wiki features to let everyone supplement the information.

Here is a starting idea for a wiki page per package.

Wiki Page Per Package

INCLUDE: Bug Tracker Summary

Open Bugs
Last bug Entered
Last bug fixed
Top bug entering user
Top bug fixing user

INCLUDE: Dependency Summary (all packages are hyperlinked)

Package Dependencies
Packages that depend on this package

INCLUDE: CVS Summary

Total Files
Last File updated, last updating user
Number of files different between the current release tag and HEAD
Most CVS updates by user

Freeform in the wiki, put in headers for each of these and people will fill them in as they can.

Description
Maturity Level

Checklist of how the package is doing on each maturity level criterion

Sites and how they have used it. Each site should be its own page with back links back to all the packages. We should be able to do this with “Pages that link to this page”
People/Companies who can answer questions about this package. Shall we let companies also have their own pages in the wiki?
Known Issues
Future Plans
Links to useful forum threads, blog posts etc.

Comments and suggestions?

To implement this the following steps need to be done.

Upgrade openacs.org to 5.2
Install XOWiki and be sure its working properly
Layout the page attractively and intelligently
Write the 3 includes
Create an index page and a page per package automagically so that all the pages interlink properly and the includes and the headers for free form are all put in.

Do we have volunteers for any of these tasks?

2: Re: A Wiki Page per Package? (response to 1)

Posted by Nick Carroll on 12/27/05 02:51 AM

Finally, a plan! Excellent work Caroline.

Since my creative outlet has been suppressed by the logo-nazis :-p I will now focus my time on the following:

Helping Dave where I can with the upgrade of openacs.org to 5.2.

I am currently working on a workflow howto guide, as I have recently had some success with it. It is quite a nice package, once you understand what is going on. I will post the guide in the wiki when the wiki gets up and running.

3: Re: A Wiki Page per Package? (response to 1)

Posted by Alfred Essa on 12/27/05 03:07 AM

Caroline, Great plan. Wiki per package is an excellent way to organize and document what's happening. Count me in for putting in some time on this effort.

4: Re: what about some movies? (response to 1)

Posted by Adam Aggeusz Jaworski on 12/27/05 04:20 AM

Excellent Plan!

as an OACS newbie and MacUser since 1998, I would like to contribute
some video movies - as those on http://www.backpackit.com - sorry for RoR link 😉
I will record them while getting familiar with core and packages
so I suppose it will be interesting show for newbies

Cheers,
Adam

P.S.
Nick! please include in this new wiki your great manual for dotFolio:
http://dotfolio.org/demo_user/files/view/ENGG1803_BlogBook.pdf
this is exactly what every package should have for end-users 😊

5: Re: A Wiki Page per Package? (response to 1)

Posted by Nick Carroll on 12/27/05 05:13 AM

Adam,

I would be interested in doing the same video presentations. How do you do yours?

Cheers,
Nick.

6: Re: A Wiki Page per Package? (response to 1)

Posted by Adam Aggeusz Jaworski on 12/27/05 05:38 AM

Nick,

I am using this one:
http://www.ambrosiasw.com/utilities/snapzprox/

I feel it can be interesting to get similar records
from different points of view, my movies will be
probably good for total newbies, since I am still
in the beginning, but yours could be from developer
point of view, so it seems we will not duplicate
efforts - I will do it anyway, just for fun 😊

Cheers,
Adam

44: Re: Re: A Wiki Page per Package? (response to 6)

Posted by Pascal Byrne on 06/07/06 03:12 PM

Nick,
A great free tool is available here http://www.debugmode.com/wink/

It allows you to save movies in Flash format and supports microphone voice overlay.

7: Re: A Wiki Page per Package? (response to 1)

Posted by Adam Aggeusz Jaworski on 12/27/05 06:01 AM

Nick,

there is also another great tool - you can save movies to flash etc.
http://www.verticalmoon.com/products/screenography/screenography.htm

Cheers,
Adam

8: Re: A Wiki Page per Package? (response to 1)

Posted by Torben Brosten on 12/27/05 07:23 AM

This is long overdue and critical to increasing quality of OpenACS.

I'm glad to help with any mindless drudgery, ie stuff for worker bees.

10: Re: A Wiki Page per Package? (response to 1)

Posted by Malte Sussdorff on 12/27/05 07:34 AM

Excellent idea Caroline. Once this is installed I will start happily writing on some packages that we work on.

9: Re: A Wiki Page per Package? (response to 1)

Posted by Torben Brosten on 12/27/05 08:01 AM

Caroline, to be consistent..

Should 4.a Description and 4.b Maturity Level be moved to 3.x INCLUDE: CVS summary (and get the info from the .info page)?

Using the same data source would help reducing the burden of updating multiple locations.

Should 4.e and 4.f be moved to 1.x (where plans and issues are posted in bugtracker) to encourage reporting everything in one place (for tracking purposes etc)?

Could the 1.x Bugtracker Summary include counts of bug severity and enhancements (feature requests)?

Could there be another INCLUDE: Code Metrics 5.x with:

a. count of tcl procs
b. count of package-key/tcl lines
c. count of package-key/tcl/test tests
d. count of pg/oracle/shared db functions
e. count of package-key/sql lines (pg/oracle/shared)
f. count of package-key/www/*.adp pages (or all adp pages in the package)
g. count of package-key/lib file pairs

see: https://openacs.org/storage/view/proposals/packages-report.html

for rough example.

The code metrics would help developers quickly realize the level of development and completeness of the code. For example, packages with a low count for tests and lib areas would indicate lacking in meeting newer OpenACS standards, whereas a high count of db functions would indicate an extra burden in maintaining 2 sets of code.

Code metrics might also be useful to others who want to contribute to rounding out a package's weaker points, or make estimates about the burden of maintaining a package etc.

11: Re: A Wiki Page per Package? (response to 1)

Posted by Gustaf Neumann on 12/27/05 11:51 AM

Nice idea! let me know if you want some more functionality to xowiki!

12: Re: A Wiki Page per Package? (response to 1)

Posted by Torben Brosten on 12/27/05 09:33 PM

and in lieu of some other automated metric for docs:

5.h count of package-key/www/doc/*.adp pages
5.i count of lines in package-key/www/doc/*

13: Re: A Wiki Page per Package? (response to 1)

Posted by Joe Cooper on 12/28/05 07:07 AM

This is a great idea indeed. Several projects I'm involved in have switched to trac for almost all development information management, and it sounds like you're proposing a very similar layout for the project wikis. trac includes a full-featured wiki, bug-tracker, version control repo browsing, and reasonable notification features. It's been a great help to have all of this information in one centralized location, and wikis are magic if the community is active. The Plone site that these tracs are replacing saw far less activity and far less user involvement, and I think, less developer enthusiasm because the lack of give-and-take of user-to-developer and developer-to-developer communication was a bit soul sucking. Seems to me that the OACS site has the same problem...all useful interaction is in the ghetto of the forums and bug-tracker, and so one has to dig to see any apparent movement or to get involved.

In short: Go!

BTW-Why isn't XOWiki in the package repository? I tried the "wiki" package thinking it was what I had seen running on a couple of OACS sites, only to be horribly disappointed by a barely limping CR-based page creator. What's in the package repo is pretty much useless, while XOWiki looks fantastic!

14: Re: A Wiki Page per Package? (response to 1)

Posted by Malte Sussdorff on 12/28/05 08:16 AM

XoWIKI is in HEAD (or was when I committed it), but due to probable license issues (as it is not GPL but BSD (I think...)) Gustaf decided not to put it there and I (accidently) uploaded it as I did not see the license statement in the code and assumed it was GPL.

Either way it is Gustaf's call to make.

18: Re: Re: A Wiki Page per Package? (response to 14)

Posted by Joe Cooper on 12/29/05 09:44 AM

I saw the thread on this, and I thought it had been resolved so I didn't bother to say anything. But I'll chime in to clarify now:

BSD is wholly GPL-compatible, unless it has the advertising clause. One can slurp a BSD package into a GPL package without license concerns. The reverse is not true, however...unless one is willing to accept a license upgrade from BSD to the stricter GPL for the whole project. GPL is viral, BSD is not.

In short, BSD is an extremely liberal license, barely above public domain. So liberal that relicensing BSD code under a different license is wholly permissible (again, with the possible exception of the advertising clause, which can either be forgiven by the copyright holder, or it can be special-cased in the GPL project...this has been done in some places in the Linux kernel).

There are a lot of thorns in the plethora of licenses out in the wild, but BSD is pretty much wholly thorn free. The only question you need to ask is whether there is an advertising clause, and if not, you're free to pull it into anything you like, including proprietary non-Open products. This is exactly the reason many folks prefer BSD. I'm not one of them, but I understand their reasons.

You've done no wrong in importing BSD code into OpenACS, Malte.

15: Re: A Wiki Page per Package? (response to 1)

Posted by Alfred Essa on 12/28/05 08:04 PM

Coming back to Caroline's outline and assuming that we all want to proceed with Wiki Page Per Package. Can the OACS gods who manage the web site make step 1. happen?

"To implement this the following steps need to be done.

1. Upgrade openacs.org to 5.2
2. Install XOWiki and be sure its working properly
3. Layout the page attractively and intelligently
4. Write the 3 includes
5. Create an index page and a page per package automagically so that all the pages interlink properly and the includes and the headers for free form are all put in."

16: Re: A Wiki Page per Package? (response to 1)

Posted by Adam Aggeusz Jaworski on 12/28/05 08:41 PM

Alfred,

they are working on this, see above:
https://openacs.org/forums/message-view?message_id=353020

there are some bugs affecting all OACS installs when initially started on 4.6
if I remember correctly, so I suppose, and believe, they are doing their best
to make it happen as soon as possible

Cheers,
Adam

17: Re: A Wiki Page per Package? (response to 1)

Posted by Adam Aggeusz Jaworski on 12/28/05 08:46 PM

"5.2.0 upgrade fixes (in progress) 5.2.0 upgrade fails on sites installed from 4.6.0 (i.e. openacs.org)"

https://openacs.org/forums/message-view?message_id=353560

19: Re: A Wiki Page per Package? (response to 1)

Posted by Gustaf Neumann on 12/30/05 01:32 AM

i see as well no immanent problem with mixin GPL and BSD-licenced code. As Andrew pointed out, the disadvantage for me could be that if someone creates a derivative work of such BSD-style packages and places these under GPL, i could not continue with this work and release it later under a BSD style license. I can live with that asymmetry. Furthermore, there is no inherent need to release a derivative work of a BSD-style package under GPL. Btw, there is an easy readable artical about derivate works in: http://linuxjournal.com/article/6366.

i have committed updated versions of xotcl-core, xotcl-request-monitor and xowiki into cvs head.

20: Re: A Wiki Page per Package? (response to 1)

Posted by Caroline Meeks on 01/10/06 04:15 AM

Status Update:

The move of the site to 5.2
is done. Dave Rocks!!

The next hard piece is writing
the includes. I’m looking for skilled volunteers to help with this.
I’m attempting to post $100 bounties on http://bountycounty.org/ for each include. It’s a good chance
to try out their system and hopefully give us some good publicity. It
isn’t much for the work but it’s a token of appreciation. If you’d
like to do it as a straight volunteer position please take the $100
and afterwards post another bounty for something else we need.

Here are some details revised
per Torben’s suggestions. Each include will take a package name as
a parameter.

INCLUDE: Bug Tracker
Summary

Open Bugs
Last bug Entered
Last bug fixed
Top bug entering
user
Top bug fixing user

INCLUDE: Info file
Summary (all packages are hyperlinked)

Description from
the .info file
Maturity level from
.info file
Package Dependencies
Packages that depend
on this package

INCLUDE: CVS Summary

Code Metrics:

count of tcl procs
 count of package-key/tcl
lines
count of package-key/tcl/test
tests
count of pg/oracle/shared
db functions
count of package-key/sql
lines (pg/oracle/shared)
count of package-key/www/*.adp
pages (or all adp pages in the package)
count of package-key/lib
file pairs
count of package-key/www/doc/*.adp
pages
count of lines in
package-key/www/doc/*

Last File updated,
last updating user
Number of files
different between the current release tag and HEAD
Most CVS updates
by user

Freeform in the
wiki, put in headers for each of these and people will fill them in
as they can.

Extended Description
Extended Maturity
Level

Checklist of how
the package is doing on each maturity level criterion

Sites and how they
have used it. Each site should be its own page with back links back
to all the packages. We should be able to do this with “Pages
that link to this page”
People/Companies
who can answer questions about this package. Shall we let companies
also have their own pages in the wiki?
Known Issues
Future Plans
Links to useful
forum threads, blog posts etc.

21: Re: A Wiki Page per Package? (response to 1)

Posted by Vinod Kurup on 01/22/06 09:13 PM

Hi Caroline,

Has anyone stepped up to the plate on these? If not, I'd be willing to start on the first include.

22: Re: Re: A Wiki Page per Package? (response to 21)

Posted by Caroline Meeks on 01/23/06 06:28 PM

Hi Vinod,

You are our first volunteer, yes please do!

XOwiki is mounted at: https://openacs.org/xowiki/

Dave wants to upgrade it at some point as more features/fixes are being added.

Please send email to Dave and he can set you up with access to the dev server for openacs.

Thanks!

23: Re: Re: Re: A Wiki Page per Package? (response to 22)

Posted by Vinod Kurup on 01/23/06 06:52 PM

Thanks Caroline,

Dave's already contacted me, so I'll get working ASAP. I'll start on the bug-tracker include, so others can start working on the other ones, if they wish 😊

24: Re: A Wiki Page per Package? (response to 1)

Posted by Vinod Kurup on 01/31/06 02:45 AM

I've finished the first 2 includes. As far as I can tell, it's not on the live site yet, but Dave will get it there in time. (Thanks Dave!)

To include a bug-tracker summary of a package in a xowiki page, type this:

{{adp /www/templates/bug-tracker {package_key lars-blogger}}}

To include a info-file summary, type this:

{{adp /www/templates/info-file {package_key lars-blogger}}}

A few notes...

The component names in the OpenACS Bug Tracker don't quite match the APM package_key in a consistent manner, so I do a switch statement to translate them. I didn't do every package, since I wasn't sure which ones were going to make it to the wiki, but I can add them as needed.
I now have sympathy for anyone who's had to work with the bug-tracker. Getting the bug tracker to divulge info it wasn't initially built to divulge is difficult.
These includes don't do any caching. I can add that if performance is a problem.
Once I figure out what the url pattern for a package will be in xowiki, I can hyperlink the packages to each other in the info-file summary
Everything is formatted in HTML tables, cuz that was easiest for me.

I'm working on the final include, but I'll probably split it into 2 includes - one for the code metrics (which doesn't need CVS at all) and 1 for the CVS data. I'm wondering if installing Jeff's CVS Log analyzer on openacs.org would be useful, so we could extract the CVS data from it.

25: Re: A Wiki Page per Package? (response to 1)

Posted by Vinod Kurup on 02/10/06 02:28 AM

I finished the code-metrics include, but it's a little expensive since it reads all the package files from the file-system in order to count lines or grep for procs. So, I've cached it by creating a proc called 'metrics'.

My question: which package should this new proc go into? I'm thinking either acs-tcl (apm:: namespace) or acs-api-documentation.

26: Re: A Wiki Page per Package Volunteers Needed (response to 1)

Posted by Dave Bauer on 02/26/06 08:16 PM

We need volunteers to go in an rename the pages for some of the packages that have names like "en:address-book 5.0d1" to "en:address-book". That is. remove the version numbers from the "Name" attribute since that is used for the URL and linking and it really isn't necesary to have a different page per version at this point.

TO help go to https://openacs.org/xowiki/ and click the edit button next to a page that has the version number in th ename.

Edit the name attribute to be en:package-key and if you like, also add a human readable title such as "Address Book" in the Title attribute. Then click OK.

Gustaf gave us a way to automatically add the bugtracker and info file includes to pakcage pages, so I'll be doing that soon as well.

Thanks!

28: Re: Res: Re: A Wiki Page per Package Volunteers Needed (response to 26)

Posted by Emmanuelle Raffenne on 02/27/06 12:08 PM

Hi,

I've renamed pages for dotlrn-all and dotlrn-extras modules, and a few more. I will continue with remaining pages during the week.

27: Re: A Wiki Page per Package? (response to 1)

Posted by Nick Carroll on 02/27/06 08:46 AM

I just edited a couple, and they still have the en: prefix after submitting a title with the en: prefix removed.

29: Re: A Wiki Page per Package? (response to 1)

Posted by Dave Bauer on 02/27/06 02:59 PM

Nick,

The en: defines what language the page is in. Its OK if that is in the Name.

Thanks!

30: Re: A Wiki Page per Package? (response to 1)

Posted by Nick Carroll on 02/28/06 12:49 AM

Personally I don't like the prefix. I think it should be positioned to the right of the title. For example:

ACS Admin [en]

instead of

en:ACS Admin

Or better yet, display the country's flag for that specific locale instead of [en].

If that wiki entry were to be translated, then it would look like the following:

ACS Admin [en|fr|db]

Would this be a better approach?

32: Re: Re: A Wiki Page per Package? (response to 30)

Posted by gustaf neumann on 02/28/06 01:17 PM

All xowiki pages have a "name" and a "title". The "name" is a shortname that has to be unique per folder. xowiki supports page title since a few weeks and uses since this time title instead of names for labeling things. Since the language prefix is only part of the name, you should not bother about it.

It seems as if dave does not have currently the time to catch up with the developments in xowiki, so the installation of xowiki on oacs.org is quite old. dave uses a customized version of the category browser. Newer versions of xowiki come with a much improved category browser (much less sql queries, opens automatically the tree for a specified page, less jumpy on the screen, etc.), and some other includelets such as one for tracking recently changed xowiki entries similar to "recent posts" on the oacs start page, etc.

i would suggest to wait until the newer stuff is in place. It is quite simple to provide alternate category renders, e.g. by registering a mixin (the renderer is less then 20 lines of code). Currently, i am not sure, what the best way to display categories in a multi-lingual setup is, since the categories themselves have different labels, and once we have 10 or more languages, the flags might look silly.

31: Re: A Wiki Page per Package? (response to 1)

Posted by Nick Carroll on 02/28/06 01:13 AM

I have just completed the modifications to all the ACS packages, and the packages that I am responsible for.

33: Re: A Wiki Page per Package? (response to 1)

Posted by Dave Bauer on 03/01/06 07:42 PM

Gustaf,

I added the new version of xowiki, but the category tree does not seem to be collapsible.

Maybe I missed something in the update.

34: Re: Re: A Wiki Page per Package? (response to 33)

Posted by gustaf neumann on 03/01/06 08:26 PM

if you include the portlet by hand to the view.adp page, you should add
<link rel='stylesheet' href='/resources/acs-templating/lists.css' media='all'>
<script language='javascript' src='/resources/acs-templating/mktree.js' type='text/javascript'>

35: Re: Re: Re: A Wiki Page per Package? (response to 34)

Posted by gustaf neumann on 03/01/06 08:27 PM

oops, to fast...

...as well to the page. in order to open at the right page,
pass open_page="@title@" to the adp-include.

36: Re: Re: A Wiki Page per Package? (response to 33)

Posted by gustaf neumann on 03/02/06 03:13 AM

dave, i saw, you did this already. It looks to me as if the .js file must precede the .css file for mktree to work. i would also recommend to put the content part of the pages into a >div< with "float: right; width: 74%; top: 0px;" to avoid the strange page flow; if 74% is still to large, use 73 etc....

37: Re: A Wiki Page per Package!! (response to 1)

Posted by Caroline Meeks on 05/26/06 03:56 PM

I wanted to remind everyone that we have this resource and that people are starting to use it.

My vision on how it could be used:

If someone has a question about a package the wiki is thier first stop. It becomes usefull if people have done the following:

1. Developers make note of thier current work and intentions if they are acitve on a package.
2. Developers as you are working on things if you have an insight make a note of it there.
3. Volunteers and newbies, when you find the answer to your question in the forums or from help on IRC etc. make a note of it and/or link to it on the relevant wiki page so that the next person can find it.

Remember this is a wiki not the offical documentation. I think its fine to state your opinions not just the facts. I think opinions are valuable. In OpenACS there is almost always more then one way to do something. We often strong opinions about the right way. Experienced people may not always agree but our disagreements are usually educational and we often agree that newbies do it wrong :).

When should you post in the forum and when should you write in the wiki?

If you want an opinion from a wide range of people or you need an immediate response - use the forums.

If you were sitting next to a teammate who was working on the same package and you'd tell him what you just learned then write that in the wiki. The person who works on that package next month will thank you.

38: Re: Re: A Wiki Page per Package!! (response to 37)

Posted by Malte Sussdorff on 05/26/06 06:14 PM

Do we have notifications or RSS feeds for changes in the XoWIKI, so you could follow this as well?

39: Re: A Wiki Page per Package? (response to 1)

Posted by Dave Bauer on 05/26/06 06:35 PM

Malte,

https://openacs.org/xowiki/?rss

See http://media.wu-wien.ac.at/download/xowiki-doc/ for more ways to query for RSS.

I'll try to figure out how to get an RSS link on every page.

41: Re: Re: A Wiki Page per Package? (response to 39)

Posted by Malte Sussdorff on 05/29/06 11:26 AM

According to the documentation I guess {{adp portlets/rss-button}} should give you the RSS button.

As for the queries, this works nice, now I am just wondering if I could get the Feed in HTML, as bloglines provides the new entry as one large line.

Last but not least, is there a Wiki "DIFF" function which would highlight the changes in the RSS feed ?

42: Re: Re: Re: A Wiki Page per Package? (response to 41)

Posted by Gustaf Neumann on 05/29/06 06:02 PM

One can make the button in many different ways, the link (that dave posted) is quite simple to use wherever you want. The adp-macro is just a conveniance function...

The rss-content is per definition plain text. However, there is as well a weblog-style interface for the content. https://openacs.org/xowiki/pages/en/weblog

oacs.org needs an update of the mktree.js file, which has by default the problem of making multiple + symbols when loaded multiple times. I have fixed this problem in mktree.js some time ago, just updateing should help...

no, there is no Wiki "DIFF" function which highlights the changes in the RSS feed. i am not sure what you imagine, since the RSS feed is typically providing new entries, and RSS itself contains only plain text (no HTML), so coloring
the entries is not possible. If someone writes a good HTML-diff function, it could be technically possible to provide a link from the the RSS-feed to show some differences...

43: Re: Re: Re: Re: A Wiki Page per Package? (response to 42)

Posted by Malte Sussdorff on 05/29/06 06:53 PM

With regards to the rss-content, I thought that it would be possible to choose HTML due to the RSS feed generated from TUAW (http://www.tuaw.com/rss.xml):

<?xml version="1.0" encoding="UTF-8"?>

<?xml-stylesheet href="http://feeds.tuaw.com/~d/styles/rss2full.xsl" type="text/xsl" media="screen"?><?xml-stylesheet href="http://feeds.tuaw.com/~d/styles/itemcontent.css" type="text/css" media="screen"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" version="2.0">

<title>The Unofficial Apple Weblog (TUAW)</title>

<description>The Unofficial Apple Weblog (TUAW)</description>

<image>

<url>http://www.tuaw.com/media/feedlogo.gif</url>

<title>The Unofficial Apple Weblog (TUAW)</title>

</image>

<generator>Blogsmith http://www.blogsmith.com/</generator><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" href="http://www.tuaw.com/rss.xml" type="application/rss+xml" /><item><title><![CDATA[Weekend Review: this week's software]]></title><link>http://feeds.tuaw.com/weblogsinc/tuaw?m=280</link><guid isPermaLink="false">http://www.tuaw.com/2006/05/28/weekend-review-this-weeks-software/</guid><comments>http://www.tuaw.com/2006/05/28/weekend-review-this-weeks-software/#comments</comments><description>Filed under: <a href="http://www.tuaw.com/category/software/" rel="tag">Software</a>, <a href="http://www.tuaw.com/category/weekend-review/" rel="tag">Weekend Review</a><div id="pc622660"><img vspace="5" hspace="5" align="right" alt="" src="http://www.tuaw.com/media/2006/05/BricksmithIcon.jpg" />Grab a cup of coffee and get your downloading mice ready ladies and gents; this week's software review is coming at you: Shareware

<ul>

..... many more lines ....

As for the DIFF, I imagined getting the new HTML page with the background of the changed pieces highlighted. But I guess the link to an HTML-diff function would be fine. OTOH not something I really need, just thinking out loud.

40: Re: A Wiki Page per Package? (response to 1)

Posted by Dave Bauer on 05/26/06 06:54 PM

Or probably better

https://openacs.org/xowiki/?rss=10d