Home Reinforcement Learning and Artificial Intelligence (RLAI)
 Suggested changes to the open page infrastructure
 --Anna Koop, Aug-Sep 2004 --Rich Sutton, Aug-Sep 2004 --Priyanka Pareek, Aug-Sep 2004
The ambition of this web page is to describe and discuss possible changes to the interface and software underlying open web pages.  This is the place the open pages magicians list their "to do" lists and other plans for the future.  This is also the place for any and everyone to make suggestions about the open page system as a whole.  The best way to make suggestions is to append them to the end of this page using the extension mechanism, i.e., by clicking the extend link at the bottom of this page.  Be sure to check the "Notify subscribers" box on the extension form, so that those who might address your suggestion are automatically notified of it.  If your suggestion, question or comment is about a particular open page, then it would be better to put it on that page (by extending that page).

Text in orange were added, for example, to an existing extension.  Items in purple are slated for being removed from this page and added to the suggestions archive.  Some older versions of this page are here and here.

As of Oct 11, 2004 we have been officially running OpenPages 1.0.

We have also been running OpenPages2, even though it is really best thought of as a beta, and probably will never be completed.  Here is a sample page from the new system.  It shows promise, but probably cannot compete with large efforts such as google sites and WYSIWYG wikis and other open source projects that are sure to follow.  And because of that, we are no longer actively developing either open page system.

A New Proposal for OpenPages 2

see here.  an even newer proposal, based on in-browser editing, is starting to be formed here.

Proposals for OpenPages 2

OpenPages 2.0 will be based on membership and the complete elimination of filenames.

It will permit pages to be restricted to subsets of users, separately for reading, extending, and editing.

It will include a better subscription model, with subscription and anti-subscription to whole trees of pages.  This will require editors to indicate which linked-to pages should be considered child pages and which not.  In fact, we should maintain bi-directional child-parent links, but that part can be automated.  It might be best to do this improvement before a full OpenPages 2, as it does not require membership.`

Suggestions for changes to OpenPages 1

Highest priority:
  1. Archiving - Finished! Anything else needed? Possible additions: a link to the different versions of a page on each page, a way to automatically revert to an old version (maybe not a good idea), a nicer looking diff display.
  2. Let subscribers desubscribe by email without human administration.  Is this really done yet?  Does it work?  What about de-subscribing for addresses other than the account i am replying from (because of email forwarding)? This is done, including the email forwarding problem.
  3. Making the subscriber list publically viewable (but not machine sniffable) I think this can also be declared done.

Problem: the page that you get after "Help" and "Click here" makes multiple references to /openpageinfrastructure/emailForm.html, but this page was never made. I put a dummy page there, pointing to anna. -rich 

If fixed the multiple references to the emailForm page in the troubleshooting section. For now, it is just set as a mailto:anna@cs.ualberta.ca link.

We were going to make a page with a form which could be redirected to whoever was in charge of troubleshooting, but I guess we didn't get to that.

Newly created pages should automatically set the title to be whatever is the first line enclosed by h1 tags, if it is the default title. 

This is a suggestion for something new. New functionality.

Something our users want is reliability, in particular, permanence. They want good reason to believe content in an open page will never be lost. They want the ability to cite an open page in such a way that they will always get the content of that page as it was at a certain time rather than as it has been changed to be. Moreover, we would like this to be done securely so that the content truly cannot be altered or destroyed, ideally even by system wizards....

Ah, but really, thinking again, this is a functionality separable from open pages. Useful in open pages, but better to be separated from it. It has many uses other than open pages and is really a totally different focus that needs a full attention to it alone. I will send an email about the "Permanent Data Registry" as an idea for a new business.


It is possible with the archiving that is in place right now to refer to a particular version of a page. (A page as it was at a certain time). For example, to get version 1.15 of this suggestions page use this link: /OpenpagesArchive/viewcvs.cgi/*checkout*/www/openpageinfrastructure/suggestions.html?rev=1.15. Or, just to get a list of versions for a page use /OpenpagesArchive/viewcvs.cgi/*checkout*/www/openpageinfrastructure/suggestions.html

I don't think it's possible to create some kind of archive that is truly impossible to destroy. Pretty much if it can be created then it can be destroyed. But, we can make it so that only administrators have that potential, and so as long as they do things correctly the archive should be stable. 

Ok, so the viewcount on every page is up. It's at the bottom right of every page. Also, there's a link to the Archive at the bottom of every page. Overwrite protection is also done. If you start editing a page in Mozilla and someone else changes it in the mean time then you won't be able to publish.

The emails that OpenPages sends should be formatted better. With a proper from and to field. And the subject line has been shortened. Also, these changes in the emails are now in extension notifications AND general notifications (when you click on notify).

If a new page is created and the title is not set, then it is taken from the first h1 field. There is a problem with this though, because the missing page doesn't use h1 for it's title heading, so you have to explicity switch to using h1.

That's all for now. Formatting the cvs diff in the archive is proving to be quite challenging. 

Email discussions can now be recorded to an open page. Simply include rlai@cs.ualberta.ca as one of the recipients as follows:


Where pagename is the name of the page (openpageinfrastructure/suggestions.html) for the suggestions page).

You have to put page:in front of the page name for now. That was a temporary design decision to make sure other emails aren't confused as openpage email discussions.

If the page does not exist, then it is created, with the subject of the email used as the title of the page.

There is no parsing of the email done at the moment. The whole body of the message is taken as a new extension as-is. So, if you have previous emails in the discussion quoted:

> previous message
current message

Then the quoted part will be included in the new extension, even though it has already been included in a previous email/extension.

This is just the initial stage. Improvements are on their way. 

You can't replace a page you have edited (that is, you have to close the file you're working on and re-get it in order to add to your own changes) and Help->Check Here for publishing error reasons doesn't tell you anything. 

I think we may need to generate some kind of notification, say to a page's designated editor, every time the page is changed, even trivially, and whether or not the author does an explicit notify.

This would prevent surrepticious authoring and thus some kinds of abuse. This would enable editors to track all changes so that she can decline them or modify them if necessary.  

I guess the main problem with this is that currently Open Pages has no concept of a designated editor. There is a subscriber list, but that is all. Perhaps
this is a concept that should be implemented? Otherwise this notification would have to be sent to the whole subscriber list.Mark Lee, Mon May 30, 4:00 pm

Another bug in something important that used to work: i can't publish and republish the same page. This is essential to the user experience. He should not hesitate to save and preserve her work.

Anna, did you do this before by checking the user/source of the last publish, allowing a technically out-of-date publish if from the same user?


Republishing used to be implemented by checking the IP address of the modifier against the IP address of the last modification - if they were the same, the change was allowed. I don't know how the checking works now, so I don't know if this is easy to implement.

(see my comment a bit higher on the suggestions page) Also, the Help-> I tried to publish and it failed link does not contain any useful information anymore. I don't know if there are any error messages any more.

Can we respond to OpenPage emails?  

Ok, now it is possible to republish and republish the same page. However, if your version has become out of date then publishing will still fail. So it should all be working good.  

About responding to OpenPage emails: Currently it is not possible to simply reply to a notification. However, this is an interesting idea and would be quite easy to implement.  

Regarding the format of the "notify" email:
I find it hard to immediately read the most important information, because it's not separated by whitespace. I think the clutter detracts from the possibility of using open pages as a mailing list replacement. Mainly, the automatically generated text should be less obtrusive.

For example, here's the current format:
A change has been made to /RLAI/labInfo.html, an open web page to which you are subscribed.
The author of this notification is Anna
The author has summarised the changes as follows:
I just added the software/tools policy to the lab web page. And subscribed everyone in the lab who wasn't already subscribed.

Remove yourself if you must, but it shouldn't be high traffic.

To unsubscribe anna@cs.ualberta.ca from this page, reply to this message with the subject REMOVE (make no changes to the message body).
The "A change has been made to . . . " line is informative, but the page is now in the subject line, which is great. So I already know the most important part of the information in the first line, from the subject, and it's not that important to read it again. Could it go at the bottom?
"The author of this notification is . . . " also not that informative. The name is.
It's hard to pick out where the actual text written by the person begins and the automatically generated text ends. So, I propose something like this:

From and Subject line of the email itself remain as they are, or possible from changes to "Anna, via the OpenPages Bot" or "Anonymous, via the OpenPages Bot" if nothing was entered.

The email itself, using the above message as an example:
I just added the software/tools policy to the lab web page. And subscribed everyone in the lab who wasn't already subscribed.

Remove yourself if you must, but it shouldn't be high traffic. (Note that this is all the text that the notifier entered)

Anna (the name as entered by the notifier)

---- (some kind of separating line)
A change has been made to /RLAI/labInfo.html, an open web page to which you are subscribed.
The author of this notification is Anna

To unsubscribe anna@cs.ualberta.ca from this page, reply to this message with the subject REMOVE (make no changes to the message body).
----------------------------- (end email)

Or something like that. But the automatically generated text should be much less intrusive.  

You are absolutely right Anna. I have been meaning to update this form for some time...and i am still meaning to do it...pretty...soon. -rich  

The counter link at the bottom of the page now displays the number of visitors and the number of subscribers. Also, the trailing space was removed. -Mark  

little problem: Extensions seem to lose any tabs in the submitted text.  

Better way to handle notifications and email discussion... might be to show an email address for the page. email to that address goes to the subscribers but is otherwise like ordinary mail. in particular you know who it is from and can reply to it. Users can either click on the address shown on the page or cut and paste it into their email client.

this will eliminate questions about how to format the email message sent on notifications. (still an issue on extensions though.)


The extend submission form needs to be slightly taller (button is half cut off). -r  

Priyanka and I thought a bit more about changing the notification process so that it works thru email. This is done by giving the page an email address that works like a mailing list with the page subscribers as the list subscribers. We thought thru the mechanism for this. The email address cannot be page specific - it must be to the openPageBot@cs.ualberta.ca (or whatever) so we have to put all the information identifying the page in the quoted part of the email address. We are thinking the way to do this is just to put the url in the quoted part. it will be kinda long, but clear and relatively easy to remember and even create by hand.

But we should think -- it this really a good idea to involve email in sending/changing, or is it better to have all that work thru a browser, reducing the number of software components involved?


Ok, it is now possible to email all the subscribers of an openpage. For example, to send a message to the subscribers of this page you would send to:

"subscribers:openpageinfrastructure/suggestions.html" <rlai@cs.ualberta.ca>

Then all the subscribers would receive a message from you, addressed to the subscribers. At the bottom of the message is instructions on how to unsubscribe.

There is now a directory in openpages that is "semi-private". All files in rlai.cs.ualberta.ca/private are publically viewable, but only those who know the username and password can edit or create a page.

How are the username and password set for a private page?

And, "private" is not quite right, as the pages are publically viewable. i'm not sure what is right. "controlled"? a bit too negative. maybe "protected". or "group" because they are editable by a specific group.


We've got a big bug right now! Extensions with long lines are not wrapping! Users are getting unreadable extensions - as in /RLAI/rewardhypothesis.html. This must be fixed right away. -rich

alright. Should be working fine now.

Rich, do you mean in the emails that are sent to subscribers, or long lines on the actual open page (or both)?


It feels like it should be easier to reply to an email notification (like this one) with a note to the author. Perhaps a reply to field on extensions and notifications?

Also, i have a sneaky idea for pages that are editable by a restricted group of people. In short, we have an _unlinked page_ (my new name for an unlisted page - it's a page with no links to it!) and we have an _alias_ to it, a sort of _dark link_. The alias is the public name. It is a file in an /alias/ subdirectory that does php or something and creates the page when asks for by making a copy of the page at the secret url. Thus anyone can read the page via the alias, but only those who know the secret (real) filename can edit it (in the normal way). Thus, no usernames or passwords, just unlinked pages, which we have already established (and which require no infrastructure other than documentation).

When you try to create a new page in the alias/ subdir you are instead asked to provide the secret url.


I would like to add another link to the bottom of the page. The link "Email" should pop up a window telling about the email features of open pages and, most importantly, giving the email address for that specific page in a convenient form for cutting and pasting into an email message.

We should also lose the link "subscribers" by merging it with the final link which gives info on the current page. We could just list the subscribers there. This will free up room on the last two lines for "email".

We could also take the "by the RLAI group" from the last two lines to free up even more space.


Now that emailing to subscribers is working without needing the web-based form, I'm happy, but I think we need an unsubscribe link to be appended to the message.  

Problem: restore on this page: /RLAI/RLAIcourse/RLAIcourse.html
generates an

"Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request."


Restore error has been fixed.


Aliased pages now have a different footer then regular pages. Final tweaking of the new footer is probably required, however.


Removed the requirement that alias pages end with .cgi

Added a header to alias pages that say they are read-only

Was does it mean to subscribe to an alias page?


Error messages caused by publishing errors should now be much more likely to work through the "Help' link.  

There was a small bug in the viewpublishlog script, but that has been fixed now. Everything should be working good.


I am a little concerned the terminology of "extend", as in "Extend this page" is not very clear and welcoming.  It should be more transparent!  Maybe the link needs to be "Add a note" or "Comment".

The extend and notify forms have been updated. As well, the emails sent for extensions and notifications are almost finished (the unsubscribe part is not quite done).  

Don't let notify window be closed without warning of message lost.  

Stats page should include date since along with page-view counts.  

Extend this Page   How to edit   Style   Subscribe   Notify   Suggest   Help   This open web page hosted at the University of Alberta.   Terms of use  6446/4