Forum OpenACS Development: xowiki 0.20

Collapse
Posted by Gustaf Neumann on
The new version xowiki 0.20 is in CVS head. Since 0.18, i have added various features like e.g. search, import/export, configuring start page, programmable wiki objects, plugin for categories etc. to XoWiki. The documentation reflects most of the new stuff, the sections Folder Object, ::xowiki::Objects, import/export are new. For understanding ::xowiki::Objects, see the hello world example.
http://media.wu-wien.ac.at/download/xowiki-doc/index.html

For fun, i have modeled the oacs home page as wiki page. The structure is decribed in the documentation as well.
http://media.wu-wien.ac.at/download/xowiki-doc/oacs-home-page.png

For people not using CVS, get the apm-files for xowiki and xotcl-core from http://media.wu-wien.ac.at/download/

Collapse
2: Re: xowiki 0.20 (response to 1)
Posted by Nima Mazloumi on
Gustaf: This is brilliant. Thank you very much for your work. I really love the OpenACS website you did with XoWiki and wouldn't mind it would replace the current :)
Collapse
3: Re: xowiki 0.20 (response to 1)
Posted by Dave Bauer on
Nima,

I agree. We just need someone to make the Selva theme work on a stock openacs install without .LRN.

Collapse
Posted by Gustaf Neumann on
Hi folks, i have checked into cvs HEAD a small extention to xowiki, that implements the client and server side of a ajax based chat system. This is implemented via the programmable xowiki::Object class. i have implemented the system from scratch, since, i was just interested in getting some experience with ajax, but - aside from javascript quirks - this worked quite nicely. Here you can see an xowiki page with categories and the xowiki chat embedded.
http://media.wu-wien.ac.at/download/xowiki-doc/ajax-chat.png
Login into the chat happens simply by loading the xowiki page. I have tested with safari and firefox.

in order to try the xowiki ajax chat, load the following file from the browser and you will create in that xowiki package instance a page named en:ajax-chat.

http://.../xowiki/admin/samples/ajax-chat

I have tried to make the display as flicker-free as possible, this works quite well. every chat is identified by a chat-id, which could be in general a package_id, community-id, or whatever. the chat-id is configured in the wiki-page and is set currently to 22. There are some more limitations: Currently, only one chat is allowed per browser. if the login times out, the background process is not able to login automatically. so far, the chat is volatile, that is, the messages are not logged to the database or to some log file, but that's not complicated at all.

The length of the code in the content-part (you will see this by editing the page) can and will be reduced, such that only the configuration stays there. i am not sure yet, how much of this should go to the library...

Collapse
Posted by Hamilton Chua on
Coolness !!!!

I don't know if this will help reduce the code in the "content-part" but I put together a little Ajax Helper package that uses the prototype.js and scriptaculous javascript libraries.

It's currently in use in a custom Tag Cloud package in Solutiongrove's Aspen Private Label Communities product and an ongoing project that uses xowiki and portlets.

The package also allows you to use tcl to generate the javscript for cinematic effects like fades and transitions so you can actually put transition effects when the chat screen is updated via ajax.

I was hoping to commit it to OpenACS Head once I've completed the documentation and demos.

Collapse
Posted by Gustaf Neumann on
the "content-part" is currently 25 lines (including the form, url-definitions, etc.) and should be reduced to 10 or so. i am not sure, whether the .js libraries your are mentioning will help with that.

the bigger question is, how many XMLHttpRequests for one browser we want to have more or less in parallel, how to address the multiple instances of one app in browser windows/tabs (names of dom elements), how to bundle/multiplex multiple inquirers in a single HTTPrequests and answer sets. In other words, would not be optimal, if for every ajax application instance, separate XMLHttpRequests whould be created, all of these polling the server for updates. one poll should provide data for all inquirers. registering callbacks in js look like a good idea...

The situation might be different in your situation, i would assume, that once the "cinematic effects" are done (whatever these are) no more requests are needed.

Collapse
Posted by Hamilton Chua on
Hi Gustaf,

These are the same big questions that I dealt with when I was looking into xmlhttpd about 1 year ago when it started gaining momentum. But then things got busy and I was unable to pursue it.

It's a good thing too because between then and now a plethora of javascript libraries and ajax toolkits have been released that address those same questions.

I've just committed to OpenACS CVS Head the Ajax Helper package. Instead of re-inventing the wheel I decided to re-use what is available by utilizing Scriptaculous and the prototype javascript library.

http://cvs.openacs.org/cvs/openacs-4/packages/ajaxhelper/

A demo site will follow very soon.

Cheers,

Hamilton

Collapse
Posted by Rainer Hahnekamp on
Hello Hamilton,

I've tried out your AjaxHelper package and find it is a very useful addition for OpenACS. But I am afraid it produces too much overhead.
If I have for example a page where I only want to use that bubblecallout feature - which should be a very trivial one - the loading time of the page increases from approximately 1 second to over 6 seconds!
Perhaps one can reduce the amount of javascript files that are loaded by default to an absolute minimum.

Greetings,
-Rainer

Collapse
Posted by Hamilton Chua on
Hi Rainer,

Thanks for the feedback.

Hamilton

Collapse
19: ajax helper demo (response to 16)
Posted by Hamilton Chua on
Oh and have you seen the demo ?
It's on a temporary server

http://sgsandbox.com:8002/xowiki/demo

username : mailto:demo@solutiongrove.com
password : demo

Collapse
20: Re: ajax helper demo (response to 19)
Posted by Gustaf Neumann on
wow; this is looks indeed very nice! maybe this is developing to an alternative to the portlets + portal pages...
Collapse
21: Re: ajax helper demo (response to 19)
Posted by Malte Sussdorff on
I seriously hope this develops into an alternative to the way we handle portlets and portals at the moment. I'm missing though a "save" function :).

Furthermore it does not work on Safari.

Collapse
Posted by Gustaf Neumann on
another thing to mention: in the current version, a user cannot chat to himself: in order to minimize the traffic, the chat remembers for every user_id the timestamp he has already seen, and sends only newer messages (happens via nsv_*). so one needs 2 users to try this out.
Collapse
Posted by Gustaf Neumann on
there is a new version of my ajax based chat package checked in cvs HEAD, most of the mentioned shortcomings are removed. Every chat client has a session-id now, a single user logging in from two browsers or two browser frames gets now a different id, so the user can to himself - not, that this is important, but should work anyhow. the chat works now with IE as well.

if you edit the page en:ajax-chat, you see that its contents are reduced now to

proc content {} {
::xowiki::Chat login -chat_id 22
}
By removing the chat_id, per default the package_id is used as chat_id (this means one chatroom per package instance). If it is left as it is, no matter from which instance of xowiki this is coming, the chat connects to a chatroom with chat_id 22.

Collapse
9: Re: xowiki 0.20 (response to 1)
Posted by Sam Nicholson on
Indeed, this looks fantastic. A couple of Qs.

1) Does this work in 5.2.x ? Pardon if I missed this.

2) If so, how can this be tracked with cvs in a 5.2 installation?

3) Does this depend on .lrn features? Q comes from looking at the png of your demo OACS home page, and from comments on your doc page.

Thanks!

Collapse
10: Re: Re: xowiki 0.20 (response to 9)
Posted by Gustaf Neumann on
1) Does this work in 5.2.x ?
yes, it works with 5.2.*, but it is not part of 5.2.

2) If so, how can this be tracked with cvs in a 5.2 installation?
check out xotcl-core and xowiki from cvs head, this will work with your oacs 5.2 installation. you will need xotcl 1.3.9 as well, as described various times.

3) Does this depend on .lrn features?
no. i am using the selva theme, because it is so pretty. xowiki can be mounted at the site map at various places, it creates a folder for each instance in the content repository. If dotlrn is installed, it will make use of community_ids as well.

Collapse
12: xowiki 0.21 (response to 1)
Posted by Gustaf Neumann on
Hamilton, i will give this library a look, when i have again some ajax needs.

For now, i've commited a new version of xowiki, supporting nicer urls (e.g. pages/en/gustaf instead of pages/en%3agustaf); in addtion, we have now a page_title to be used instead of lang:shortname and a creator (to be used for RSS) for all types of wiki pages.

Collapse
13: Re: xowiki 0.21 (response to 12)
Posted by Carl Robert Blesius on
Gustaf, why did you pick pages/en/gustaf rather than pages/gustaf/en (or pages/gustaf?lang=en), where the absence of the /lang flag would serve the default? Somehow pages/en/gustaf seems clunky (although it is much better than en%3agustaf btw :-))
Collapse
14: Re: Re: xowiki 0.21 (response to 13)
Posted by Gustaf Neumann on
well, the reason, why en:gustaf looks bad with oaces lies at least in part in the ns_urlencode, which i did not want to cirumvent. wikipedia uses unencoded colons in links (see http://de.wikipedia.org/wiki/Bild:Netz_ASEAG_um_1933.png). Anyhow, moving from en:gustaf to en/gustaf is a simple step, and makes the user think, there is a directory of english pages, which sounds like a good metaphore to me. this is certainly as well a very crawlerfriedly version. Using /en as a suffix sounds not so good to me, but this is rather a subjective argument. by any of these nameing rules we are reducing the range of valid names; e.g. "a/b/c" is so far a valid name of a page, Telling a user, "use $lang/name" sounds to me as a more intitive rule than "name must not end with /$lang" or similar. The overall wiki conventions are based on prefixes, so why to switch to suffixes. Certainly, using "?lang=en" is an option as well, but the basic idea of nice urls is to make these free of query parameters...

making the language optional is not something i would emphasize right now, since this can lead to serious misunderstandings, depending on how the default language is determined. If this is based on the user preferences, a link like pages/gustaf would lead to a page of the users prefered language. however, what if the pages in these languages are sparsely populated, etc. If two people look at a page wuth the same link and they see different pages, this can lead to some confusion. The automatic language completion sounds more suited for a well maintened set of pages (e.g. learning materials) than for a rather chaotically developed set of information chunks. So by default we should be precise on the links. btw, the language can be made optional in all variants.

Remember, we are talking about the links showing up in the listing of all pages, or from the category listings, or between wiki pages. Within a wiki page, a user will/should use [[gustaf]], or [[en:gustaf|Gustaf Neumann]] or whatever to refer to appropriate page. The links from wiki pages are generated at the time of rendering based on the language preferences. We are talking about beauty of these generated urls....

Collapse
17: xowiki 0.22 (response to 12)
Posted by gustaf neumann on
Once again, there is an updated version of xowiki in cvs HEAD; i have added permission handling (based on package_id; new link in admin page), fixed permission context for package instances, made update scripts more robust and unified pretty-url handling.
Collapse
15: Re: xowiki 0.20 (response to 1)
Posted by Gustaf Neumann on
i have added some small enhancement to xowiki, that some of you might find useful. In a large repository of wiki entries, it is not so easy to find out, what has changed. therefore i have added two includelets. The first one ("categories-recent") shows the n most recently edited pages by categories, somehwat similar to the Recent Posts of oacs.org. The second one ("recent") is a simple flat listing of the n most recent edited pages.

>right-col
{{adp portlets/categories-recent {name {Recent Entries by Categories} max_entries 5 tree_name Purpose}}}
{{adp portlets/recent {name {Recent Entries} max_entries 10 }}}
>

This snippet is shown rendered in the left side of the screenshot
http://media.wu-wien.ac.at/download/xowiki-doc/recent-entries.png

The changes are in cvs HEAD as usual.

Collapse
22: Re: xowiki 0.20 (response to 1)
Posted by Dave Bauer on
Gustaf,

I was no able to resolve the issue with package_id but I worked around it

Changed in Page instproc render

set package_id [db_string q "select package_id from acs_objects where obj\ect_id=:parent_id" -default ""]
# set package_id [$parent_id set package_id]

and in www/portlets/categories.tcl

the same kind of change. Now its more or less working :)

Al;so we notice to Xinha editor isn't coming up. I didn't see any javascript erros and I haven't had time to debug it yet.

Thanks for the great work improving xowiki!

Collapse
23: Re: Re: xowiki 0.20 (response to 22)
Posted by Gustaf Neumann on
Dave,

The real problem with xowiki on openacs.org seems that it is not possible to create items derived from ::xowiki::Page. if you try to add a new "xowiki plain page" there, you see the same message as showing up with the folder object:

Database operation "dml" failed (exception ERROR, "ERROR: insert or update on table "xowiki_plain_page" violates foreign key constraint "xowiki_plain_page_ppage_id_fkey" DETAIL: Key (ppage_id)=(395917) is not present in table "xowiki_page". ")

The same happens, when trying to create page templates. Here is the type hierarchy of the pages.

object_type       |      supertype
------------------------+---------------------
::xowiki::Page | content_revision
::xowiki::PlainPage | ::xowiki::Page
::xowiki::PageInstance | ::xowiki::Page
::xowiki::PageTemplate | ::xowiki::Page
::xowiki::Object | ::xowiki::PlainPage
An insert with content_item__new into with a object_type of e.g. ::xowiki::PlainPage is supposed to insert into xowiki_plain_page and xowiki_page. This works normally nicely, but seems to fail on openacs.org (interpreting the above error message). The same thing happens, when xowiki tries to create the directory object (of type xowiki::Object), which makes under normal conditions an entry in xowiki_object, xowiki_plain_page and xowiki_page. This was the place, where the error popped up.

Either there is something seriously wrong with the handling of derived types in the CR on openacs.org, or something went wrong already with earlier installations of xowiki.

Since you have only ::xowiki::Page objects so far, before digging into the details, i would recommend to go to the admin interface xowiki/admin and delete there the types for Object, PlainPage, PageInstance and PageTemplate. If you can delete these, reload xowiki from apm, and the types should be recreated magically.

If something is seriously wrong with derived types in the CR, this won't help either, but maybe something went wrong with the definiton of e.g. PlainPage in earlier installations....

oncerning xinha: by looking into the HTML source of an edit page from openacs.org, i see that the xinha javascript is not included in the edit pages. didn't you set the "htmlarea_p" to 1 in the oacs.org installation of xowiki (since the global UseHtmlAreaForRichtextP is not set?)

Hope, this helps...

Collapse
24: Re: xowiki 0.20 (response to 1)
Posted by Dave Bauer on
The types appear to be defined correctly

openacs.org=# select * from acs_object_type_supertype_map where ancestor_type like '::xowiki%';
object_type | ancestor_type
------------------------+---------------------
::xowiki::PlainPage | ::xowiki::Page
::xowiki::PageTemplate | ::xowiki::Page
::xowiki::PageInstance | ::xowiki::Page
::xowiki::Object | ::xowiki::Page
::xowiki::Object | ::xowiki::PlainPage

Looks ok to me.

The question is, why does the command to set package_id fail. How can we track that down? It would be useful to understand how to debug xotcl code, and this is a good opportunity :)

It appears that pacakge_id should be an instance var of the parent object of a certain page that already exists

the error when you try to view any existing page

can't read "package_id": no such variable
::363021 ::xotcl::Object->set
invoked from within
"$parent_id set package_id"
(procedure "render" line 8)
::365799 ::xowiki::Page->render
invoked from within
"$page render"
invoked from within
"set content [$page render]"
("uplevel" body line 30)
invoked from within
"uplevel {
ad_page_contract {
view a wiki item

This goes back to the xotcl::Object so its not just part of xowiki as far as I can tell.

I changed it to just query directly and it works fine for viewing a page. I don't know if this is related to any other issue or not.

Collapse
25: Re: xowiki 0.20 (response to 1)
Posted by gustaf neumann on
Well, got the bugger: The problem is a Postgres 7.4 vs. 8.0 issue, sitting in acs-content-repository/postgres/content-type.sql. The content-repository code in the current oacs-5.2.2 produces rules that insert for derived datatypes the tuples in the wrong order. The insert for xowiki_plain_page triggers the
fault mentioned above, since the key inserted into derived type (xowiki_plain_page) is not yet in the supertype (xowiki_page)
xowiki_plain_page_r AS
ON INSERT TO xowiki_plain_pagei DO INSTEAD
...
INSERT INTO xowiki_plain_page (ppage_id)
VALUES (cr_dummy.val);
INSERT INTO xowiki_page (page_id)
VALUES (cr_dummy.val);

If the order is changed, it works fine

xowiki_plain_page_r AS
ON INSERT TO xowiki_plain_pagei DO INSTEAD
...
INSERT INTO xowiki_page (page_id)
VALUES (cr_dummy.val);
INSERT INTO xowiki_plain_page (ppage_id)
VALUES (cr_dummy.val);
I played as well with deferring the checks, but this did not seem to work.

dave, you find the fixed rule generator in george:~gustafn/create-rule.sql

Most likely this will fix the bug #2810 as well
https://openacs.org/bugtracker/openacs/bug?f%5fcomponent=56190&format=table&f%5fstate=7&bug%5fnumber=2810&project%5fid=56106

The same should happen with all other apps with derived types using the postgres rules for updating the views. But i guess, there are not to many apps stressing the CR in this respect as much as xowiki....

I did not upgrade the xowiki on the test-server, since we forgot the permissions for upgrading xotcl-core. But i am quite confident, that things will work nicely now. On oacs.org, updating the rule-generator +

select content_type__refresh_view('::xowiki::PlainPage') from dual
select content_type__refresh_view('::xowiki::PageTemplate') from dual
select content_type__refresh_view('::xowiki::PageInstance') from dual
select content_type__refresh_view('::xowiki::Object') from dual
+ reboot should do the trick for xowiki.

Collapse
26: Re: xowiki 0.20 (response to 1)
Posted by Dave Bauer on
Thank you Gustaf! It worked perfectly. I will work on an upgrade for the CR to fix this.
Collapse
27: Re: xowiki 0.20 (response to 1)
Posted by Luis de la Fuente on
Hello Gustaf,

I would like to have a look of your ajax based chat package. I've tried to install xowiki, but i get the following error when attempting to reach a page like http://servername/xowiki/index

----------------------------------------
invalid command name "::xowiki::Page"
while executing
"$supertype require_folder -name xowiki"
invoked from within
"if {![info exists folder_id] && ![info exists object_type]} {
set folder_id [$supertype require_folder -name xowiki]
set index_page [$folder_id ge..."
("uplevel" body line 18)
invoked from within
"uplevel {

etc...
----------------------------------------

What am I doing incorrectly?

I am quite interested in any chat package because of one of them is needed in IMS-LD, so we will integrate our develops with a chat package.

Thanks in advance,

Luis

Collapse
28: Re: xowiki 0.20 (response to 1)
Posted by Gustaf Neumann on
Luis, most probably, you have an installation problem.
::xowiki::Page is a tcl command that is loaded through
xowiki-procs.tcl. If this is not available from a connection
thread, i would expect that you see at latest
error messages when loading the procs-file.

Have you xotcl and xotcl-core installed? on your system?

Collapse
29: Re: xowiki 0.20 (response to 1)
Posted by Ben Koot on
... Have you xotcl and xotcl-core installed? on your system?

Gustaf, although you may have explained it before in response to other issues, could you please tell us what both packages do? Newbies, interested in XOwiki, will go for the full Monty, and never think about any conflicts between the packages as long as they are not made clear, hence will find themselves in trouble if installing both.

Is there no way to add a simple description to the functionality, in order to prevent people from crashing their system.

Maybe off topic, I notice XOwiki uses Xinga as editor, but OACS is shipped with the standard editor, offering less functinonality. Although not your department, we might need to find a way to sort this issue.

Cheers
Ben

Collapse
30: Re: xowiki 0.20 (response to 1)
Posted by Luis de la Fuente on
Hello,

Both Gustaf and Ben are right: problems came because I haven't had installed these packages, but I also have found problems while instaling.

I'm not really sure about what is xotcl and how to install it. I think that it does not depends on OpenACS, but... Have i to install the software in any order? Which packages conflicts with which other? Is there any help anywere?

I'll keep trying installing this software, but obviously I need help :P

Cheers,
Luis

Collapse
31: Re: Re: xowiki 0.20 (response to 30)
Posted by Luis de la Fuente on
Hello again,

I have installed all the software and the chat works well. The problems was xotcl compiling and installation, which i did incorrectly.

Thank you for your comments and help.

About the chat... this is a great job, i will research a little bit more to find how difficult and appropiate is the integration of this chat with IMS-LD conference service.

Cheers,
Luis

Collapse
32: streaming ajax based chat (response to 1)
Posted by gustaf neumann on
i have committed a new delivery protocol for chat, which is much faster and less resource demanding.

The current xowiki chat and the chat package in the ajax variant are based on a polling interface. This means that the browser asks every n seconds (per default all 5 seconds) whether there are updates available and displays it accordingly.

The new streaming ajax based variant behaves like downloading a large file when subscribing to a channel. The client opens a connection to the server and reads piecewise the information back. Therefore there is no 5 second gap and no polling necessary. In the plain aolserver, this approach would not be reasonable, since a connection thread would be blocked for every user participating in a chat. aolserver would soon run out of connection threads. I have solved this problem via background delivery thread described already in
http://www.openacs.org/forums/message-view?message_id=342566.
With the streaming interface, a client can subscribe to a channel identified by a name, and some other client can broadcast to all users subscribed by the channel. in case of the chat, the channel identifier is simply chat+$chat_id. The streaming chat interface requires libthread and a small patch for the aolserver (see link above). It does currently not work for safari, since - as it looks to me - safari allows only one xmlhttp object concurrently active (strange enough, i did not find complaints about this on the web).

While the polling ajax chat uses xml for coding the messages, the streaming variant uses JSON enoding.

With the current implementation the same chat can be used simultanously with the polling and streaming interface from different clients. The login proc tries to make a clever guess and uses the streaming interface only, when the browser is capable for multiple xmlhttp connections and when the backend has libthread.

In order to try the streaming interface, use firefox and insert into an xowiki object the content:

proc content {} {
::xowiki::Chat login -chat_id 22
}
In order to force the polling interface, use e.g.
::xowiki::Chat login -chat_id 22 -mode polling

The chat package is still using the polling interface only.
If you want to use thre streaming interface please update xotcl-core, xowiki and xotcl-request-monitor (if you have it installed).

Collapse
Posted by gustaf neumann on
The "streaming" mode described above does not work with IE. MSIE flags correctly readystate ==3 when partial data arrives, but it does not allow to access the response text (like e.g. in firefox).

so i have defined yet another delivery interface for streaming data via ajax that seems to be quite robust: instead of sending JSON encoded java script objects, it uses now a hidden iframe that recieves a text/html file in streaming mode, which includes SCRIPT-tags containing the javascript calls. i called this mode "scripted-streaming". scripted-streaming works with Firefox, Safrari and IE.

The biggest disadvantage of scripted-streaming over streaming is that while the iframe loads (always) the activity indicator spins, which makes me nervous. so, when libthread is available, firefox uses "streaming" mode, the other browsers use "scripted-streaming" mode. When no libthread is available, "polling" mode is used for all browsers. One can certainly force the mode by specifying it as shown above.

xowiki chat is at least a study how to use AJAX with oacs in three different ways.

Collapse
Posted by gustaf neumann on
To make things clearer: The streaming modes require the background delivery thread (sending large files asynchronously in the background without blocking connection threads), which requires libthread and a small patch for the aolserver (extending ns_conn) http://media.wu-wien.ac.at/download/aolserver-nsd-conn.patch

This is described in http://media.wu-wien.ac.at/download/xowiki-doc/xotcl-apm.html where the version numbers are outdated. get the actual code from cvs, not the apm packages. The file contains as well the description for installing libthread...

guess, i should move this info to oacs.org/xowiki

Collapse
33: Re: xowiki 0.20 (response to 1)
Posted by Hamilton Chua on
Gustaf,

This is really cool.

If my understanding of this article is correct
http://www.irishdev.com/NewsArticle.aspx?id=2173

We have here a COMET Web application !!!!

Hamilton

Collapse
35: Re: Re: xowiki 0.20 (response to 33)
Posted by gustaf neumann on
i am not sure that the world needs another buzzword, but actually, the two streaming modes of the xowiki chat are exactly what is sketched on that page.

if the standard scripting language of the browser would be tcl and not js, we would have had "comet" already since a few years. tcl is much more well behaved when it comes to asynchronous io than the various javascript implementations. There is a certain hope that with all that fuzz, the browsers will be more compatible in this respect in the future.

Collapse
Posted by Gustaf Neumann on
The new version of XoWiki in CVS has new functionality to track the last visited pages of a user and to track the most popular pages. This functionality can be turned off or on via a new package parameter called user_tracking on a per instance basis. The two includelets are described in the documentation http://media.wu-wien.ac.at/download/xowiki-doc/index.html .

Hope, someone finds this useful...

Collapse
Posted by Ryan Gallimore on
Hi Gustaf, What is the correct cvs command for downloading xowiki? I tried
cvs -d:pserver:anonymous@cvs.openacs.org:/cvsroot co -r HEAD xowiki
and get:
cvs server: cannot find module `xowiki' - ignored
cvs [checkout aborted]: cannot expand modules
Also, the link above to the install docs does not work. I'm using 5.2.2 and pg 8.0.3 Thanks
Collapse
Posted by Gustaf Neumann on
xowiki is not a cvs module. Use instead:

cvs -d:pserver:mailto:anonymous@cvs.openacs.org:/cvsroot checkout openacs-4/packages/xowiki

we had a severe fire damage. the machine is being replaced, most probably it will be down until early next week.

Collapse
40: Re: xowiki 0.20 (response to 1)
Posted by Daniël Mantione on
What is part of a good Wiki and still a bit lacking in XoWiki is vandalism fighting. I.e. a Wiki administrator must be able to review and revert changes quickly. Also some tools to block users and ip-addresses are necessary. To make XoWiki really usefull as a Wiki (as opposed to just a content management system) some attention is necessary here.
Collapse
41: Re: Re: xowiki 0.20 (response to 40)
Posted by Gustaf Neumann on
vandalism fighting is more of an issue when anonymous users edit or add pages. the site administrator can define who gets edit permissions on an xowiki instance basis. oacs has means to ban users. xowiki has variuos means to locate recent modifications and keeps a history of the changes that one can switch back to earlier versions.

I am not saying that we don't need better mechanism for such purposes, but we are in a different situation than the oridinary wiki. Currently i am more thinking about making the package more powerful.

btw., the good thing of an open source project is that everyone can contribute...

Collapse
42: Re: Re: Re: xowiki 0.20 (response to 41)
Posted by Daniël Mantione on
OpenACS can ban users, but not IP-addresses. The only way to stop vandals is to require user approval before they can join which is a bit against the Wiki idea. I'll consider contributing some code.

Comparing XoWiki to MediaWiki (which is what we currently run), the latter one has functionality to revert changes directly from the recentchanges screen, and clicking on a username directly shows his contributions. This is (of course) no criticism against XoWiki, just an analysis what makes the latter one powerfull.

Collapse
Posted by Gustaf Neumann on

OpenACS can ban users, but not IP-addresses. The only way to stop vandals is to require user approval before they can join which is a bit against the Wiki idea.
Good point. By looking the the increasing number of spam content on openacs.org, it looks like a good idea to ban sites (i.e. not allowing a login from banned IP-addresses or subnets) as well. The same mechanism could be used for all user-contributed content, i.e. wiki-pages, forum posts, comments on pages, oacs company listings, etc...