I tried to use a PWS for something else then a Swiki. I created a Server directory, but did not copy the files as mentioned. I copied the method initializeAll and stripped some actions. I tried to start the server but I got the message
'The path to the Server folder is wrong. Please modify the following method ...'
But the path to the Server folder wasn't wrong, there was a folder Server.
It turned out that the path to ...\Server\Swiki\page.html did not exist.
This would have been no problem if I had copied the server folder and it's easily fixed by stripping the checkVersion message send.
But the message is misleading. And I think the checkVersion method is bit Swiki minded. We should put something like that in a method called checkSwiki.
Or is PWS only meant for Swiki's?
Macarena.
Hi, I happily use PWS as a more "traditional" web server, ie, I don't use Swikis in it and it works very well. OTOH, you're right, the error message is a bit wrong.
cheers
bruce
Reinier van Loon writes:
I tried to use a PWS for something else then a Swiki. I created a Server directory, but did not copy the files as mentioned. I copied the method initializeAll and stripped some actions. I tried to start the server but I got the message
'The path to the Server folder is wrong. Please modify the following method ...'
But the path to the Server folder wasn't wrong, there was a folder Server.
It turned out that the path to ...\Server\Swiki\page.html did not exist.
This would have been no problem if I had copied the server folder and it's easily fixed by stripping the checkVersion message send.
But the message is misleading. And I think the checkVersion method is bit Swiki minded. We should put something like that in a method called checkSwiki.
Or is PWS only meant for Swiki's?
Macarena.
The PWS is definitely meant for more than just Swikis. Bolot Kerimbaev has been undertaking an extensive rewrite of the innards of the PWS, and is getting some very nice performance numbers for just plain uploads and downloads.
Thanks for the heads-up -- we'll work on the error messages during the current rewrite cycle.
Mark
I tried to use a PWS for something else then a Swiki. I created a Server directory, but did not copy the files as mentioned. I copied the method initializeAll and stripped some actions. I tried to start the server but I got the message
'The path to the Server folder is wrong. Please modify the following method ...'
But the path to the Server folder wasn't wrong, there was a folder Server.
It turned out that the path to ...\Server\Swiki\page.html did not exist.
This would have been no problem if I had copied the server folder and it's easily fixed by stripping the checkVersion message send.
But the message is misleading. And I think the checkVersion method is bit Swiki minded. We should put something like that in a method called checkSwiki.
Or is PWS only meant for Swiki's?
Macarena.
-------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
On Sat, 1 May 1999, Mark Guzdial wrote:
The PWS is definitely meant for more than just Swikis. Bolot Kerimbaev has been undertaking an extensive rewrite of the innards of the PWS, and is getting some very nice performance numbers for just plain uploads and downloads.
Mark, is Bolot using or planning on using Craig Latta's Correspondent's framework? I've just started playing with it and it is *very* interesting. Perhaps the most obvious benefit up front is that it supports Berkeley socket semantics which, I understand, will eliminate the simultaneous access problem.
Cheers, Bijan.
I'm not using Craig's Correspondents framework, but I'm encapsulating the socket interface, so it should be easy to replace the underlying layer seemlessly. I had thought of using it, but since it is part of the standard release, I felt it would be too early to adopt it. As soon as Squeak central decides to adopt a different (say Craig's) socket framework, I will switch to that. In fact, I currently recreate (fake) some of the streaming support.
I've created an "intermediate" PWS fix release, which makes it much more stable with respect to both uploads and downloads.
Currently, the application (e.g., UploadSwiki) has to "manually" retrieve the post body and parse it. However, I plan to incorporate a set of simple methods that would hide the complexity and allow you to specify the rules to apply for each field. E.g., if a field is a file, execute this block. The block would ignore or save the file in a designated directory.
The ultimate goal is to make the PWS actions/modules/servlets/handlers very pluggable, so that addition of functionality would only require overloading a small number of methods or supplying a different set of "plugs". Another goal is to keep the current PWS applications running, possibly in a "compatibility box".
And yes (answer to another email), EmailSwikiAction is in our plans. Jochen Rick (mailto:nadja@cc.gatech.edu) is working on restructuring Swikis and decoupling them from HTTP/PWS.
Bolot
-----Original Message----- From: Bijan Parsia [mailto:bparsia@email.unc.edu] Sent: Saturday, May 01, 1999 11:44 PM To: squeak@cs.uiuc.edu Subject: Re: [PWS] PWS only meant for Swiki?
On Sat, 1 May 1999, Mark Guzdial wrote:
The PWS is definitely meant for more than just Swikis. Bolot Kerimbaev has been undertaking an extensive rewrite of the innards of the PWS, and is getting some very nice performance numbers for just plain uploads and downloads.
Mark, is Bolot using or planning on using Craig Latta's Correspondent's framework? I've just started playing with it and it is *very* interesting. Perhaps the most obvious benefit up front is that it supports Berkeley socket semantics which, I understand, will eliminate the simultaneous access problem.
Cheers, Bijan.
On Sun, 2 May 1999, Bolot Kerimbaev wrote:
I'm not using Craig's Correspondents framework, but I'm encapsulating the socket interface, so it should be easy to replace the underlying layer seemlessly. I had thought of using it, but since it is part of the standard release, I felt it would be too early to adopt it. As soon as Squeak central decides to adopt a different (say Craig's) socket framework, I will switch to that. In fact, I currently recreate (fake) some of the streaming support.
Sounds very nice!
I was sorta hoping to use PWS to push the correspondents into the main release ;) If I can get it up and running, I'd be interested in mainting a parallel version.
I've created an "intermediate" PWS fix release, which makes it much more stable with respect to both uploads and downloads.
[snip]
Sounds great! Where can I get ahold of it?
The ultimate goal is to make the PWS actions/modules/servlets/handlers very pluggable, so that addition of functionality would only require overloading a small number of methods or supplying a different set of "plugs".
This sounds terrific. I strongly recommend looking at the pluggable text/list classes. All other things being equal, it would be nice to be able to apply skills learned using them to using PWS.
I've wondered whether some varient of MVC might not do well as a model for PWS. One tends to have data (models), html "views" of the data (e.g., the "browse" view and "edit" view of a swiki page) and controllers (SwikiActions?).
Another goal is to keep the current PWS applications running, possibly in a "compatibility box".
Hmm. I think I'd just leave the old PWS there. I'd rather not have a lot of compatibility cruft in a new PWS. I don't really see a *burning* need to salvage old apps *except* for swikidata.
And yes (answer to another email), EmailSwikiAction is in our plans. Jochen Rick (mailto:nadja@cc.gatech.edu) is working on restructuring Swikis and decoupling them from HTTP/PWS.
Yes yes yes! I want this for my InSqueakSwikiBrowser! ;)
Sounds good. I'd love to see some of the code. Especially since the PWS list's been so quiet!
Cheers, Bijan
By the way, as one who has only recently become alive to the virtues of PWS and built-in Swiki support, let me humbly state what a big deal this stuff is. The amount of functionality for the effort to build one is amazing, and the extensibility is unparalleled.
I am curious how, in practice, a Swiki performs. In particular, how practical are these things for communities of several hundred people?
And one simple, silly (in the sense I should probably be able to figure this out for myself without much effort) question. Since Swikis keep lots of past information available to support rollback of pages, how do I control the bilge when I am comfortable that I have a stable state? In particular, how can i get my Swiki to dump old information? Will Swiki automatically dump rollbacks after a fixed number of edits?
By the way, as one who has only recently become alive to the virtues of PWS and built-in Swiki support, let me humbly state what a big deal this stuff is. The amount of functionality for the effort to build one is amazing, and the extensibility is unparalleled.
That last point continues to amaze me. The cool inventions using the Swiki that teachers come up with are tremendous!
I am curious how, in practice, a Swiki performs. In particular, how practical are these things for communities of several hundred people?
Ward can answer for the WikiWikiWeb. My class Swiki (we call it a CoWeb -- easier to explain to students without invoking Hawaiian :-) regularly hosts over 100 very frequent users.
FYI, I've just written a paper for AERA (American Educational Research Association) on a survey of users, exploring issues of usability, motivation, and learning. http://guzdial.cc.gatech.edu/papers/aera99/
And one simple, silly (in the sense I should probably be able to figure this out for myself without much effort) question. Since Swikis keep lots of past information available to support rollback of pages, how do I control the bilge when I am comfortable that I have a stable state? In particular, how can i get my Swiki to dump old information? Will Swiki automatically dump rollbacks after a fixed number of edits?
No, the Swiki won't automatically dump roolbacks, but there are variety of commands that Ted built for trimming the load.
I should say: I've never used them. My class CoWeb is well over 1300 web pages now, after over a year of use. The whole thing, with every version of every page saved, is 50M. And in just a mere 40 years, I'll have to move off of the too-small-too-buy-a-replacement 2 gig disk that it's now residing on. Disk space is just SOOOO cheap!
Mark
-------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
squeak-dev@lists.squeakfoundation.org
-
Andrew C. Greenberg -
Bijan Parsia -
Bolot Kerimbaev -
Mark Guzdial -
O'NEEL Bruce -
Reinier van Loon