Home   Info   DevZone   Wiki  
UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
WebRCSProudctSpecificationB ] [ not logged in ] [ Web: Imported ] goto:  options
[ get info on or edit ] login or new user ] [ list of topics, hubs & nodes, or recent changes ]

Return to WebRCS page

web revision control system -- product specs
revision 0.2 - 9.3.98

1. Server Interface
 a. Installation
  i. Java 1.1 application
  ii. should have both text-only and AWT interfaces
  iii. uninstallation as well? (possible future)
 b. Web Server Integration
  i. CGI (Java Servlets)
	- Java 1.1 API only (no use of 1.0 techniques)
	- possibly look at support for Java 1.2 API
  ii. standard HTML's
	- upload/download from client
	- information presentation
	- server-side configuration
  iii. standard graphics (jpeg/gif, possibly png)
  iv. which server?
	- I personally will be developing under Apache and doing some testing with
	  MS Personal Web Server (similar to IIS)
	- should be as server-independent as possible

2. Client Interface
 a. Web Interface
	i. standard HTML's
	 - upload/download to server
	 - information presentation
	 - client-side preferences
	ii. standard graphics (jpeg/gif, possibly png)
	iii. perform standard rcs functions
	 - access (view) a resource, area, project
	 - upload a resource
	 - download a resource
	 - create a resource, area, project
	 - relocate a resource, area
	 - rename a resource, area, project
	 - build a resource, area project

3. Resource Database
 a. Security Checks
  i. server-implemented
	- useful for settings rcs-wide protection (i.e. first line of defense if the rcs
	  database is stored on a publicly-accessible website)
	- shouldn't use server passwords within the rcs database structure (may interfere
	  with normal rcs security operation)
  ii. rcs-implemented
	- can lock individual resources, areas, projects
	- can set members for individual resources, areas, projects
 b. Resource check-in
  i. be sure to check member's upload permissions for resource
  ii. use HTTP upload
 c. Resource check-out
  i. be sure to check member's download permissions for resource
  ii. use HTTP download
 d. upload/download locations (see server and client interfaces)
 e. Types of Resources
  i. files
	- source code
	- graphics
	- HTML
	- plain text
	- user-defined
  ii. notes
	- memos
	- bug tracking
	- user-defined
 f. Organization of Resources
  i. projects
	- top-most level is populated by projects
	- has a director who is "super-user" for the entire project
	- one "super-user" for the entire system (i.e. all projects)
	- stored in individual directories on web server
	- should be able to define "make" rules for a project, with
	  the ability to include areas in the build
	- can set list of members or groups who can initiate a project-
	  level "make" or "build"
  ii. areas
	- stored in individual directories under projects
	- should be able to rename areas with ease
	- should be able to define "make" rules for an area, with
	  the ability to include resources in the build
	- can set list of members or groups who can initiate an area-level
	  "make" or "build"
	- "upload/download all" (i.e. all resources contained in the area) feature
	  needed
  iii. resources
	- stored in individual files under areas
	- represent the working pieces to each project
	- should be able to rename or relocate resources with ease
	- can set individual permissions for each resource by way of
	  a list of members or groups with the following permissions:
	 + view
	 + upload
	 + download
	 + create
	 + relocate
	 + rename
	 + build
	- should be able to define "make" rules for a resource
  iv. members
	- one or more members for each resource, area, or project
	- should be able to group members into one or more groups
  v. builds
	- separated storage for finished products
	- can set list of members or groups who can access individual builds
  vi. storage
	- projects, areas, and resources are represented by directories and
	  files within the web server document root
	- all information should be maintained in a database, most likely
	  a SQL database that will be accessed using JDBC
 f. logging
  i. should keep careful track of all actions performed
	- access (view) a resource, area, project
	- upload a resource
	- download a resource
	- create a resource, area, project
	- relocate a resource, area
	- rename a resource, area, project
	- build a resource, area project
  ii. should be able to control which of the above events are logged and how much
		detail is provided (logging/debug level)
  iii. the logs themselves should be treated as a resource so as to allow access
		 control by different members

Return to WebRCS page




Content of these pages are owned and copyrighted by the poster.
Hosted by: