Re: why workspaces

Very cool!



   From: "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com>

   Another reason for using workspaces
   is that sometimes the tools required to edit, compile, or otherwise
   operate on a resource have to exist on a particular platform. That is,
   they cannot just be files in the user's local (Windows or UNIX) file
   system. Workspaces provide a uniform way of addressing resources
   regardless of where they are, or what versions are selected.

Yes, that is one of the important reason for "server side testing" support.

   But this raises an issue for testing on the server. Say you are testing
   a Web application, not an unusual situation for a WebDAV client to be
   in. Now the web server needs to see the same workspace as the client in
   order to test the resources just edited. This is the scenario you
   describe below. But often web server plugins (Servlets, JSP's, ASP's,
   CGI programs, ISAPPI programs, Apache modules, etc.) don't go through a
   nested HTTP request, they access files directly using the file system.
   This won't work unless the files are materialized on the server since
   the file system is not likely WebDAV versioning enabled. Workspaces can
   help this problem if their contents are mirrored in the server's file
   system. But then this limits the number of concurrent tests on different
   workspaces that can be done. Any thoughts on this area?

This depends on whether your testing requires a "shared resource" on
the server.  For things like compiling and running the compiled
programs, testing in parallel in different workspaces often works just
fine (since workspaces are modeled as different collections, it is
natural to map them to different points in a file system tree).  If
there is some common resource (like some database) that is required
by the tests, then you have a problem, but this is not a problem that
an HTTP protocol can address.

Cheers,
Geoff

Received on Thursday, 12 October 2000 21:05:59 UTC