Index: openacs-4/packages/acs-reference/www/doc/design.html
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-reference/www/doc/design.html,v
diff -u -r1.1 -r1.2
--- openacs-4/packages/acs-reference/www/doc/design.html 22 Apr 2001 00:53:12 -0000 1.1
+++ openacs-4/packages/acs-reference/www/doc/design.html 6 Aug 2006 18:30:57 -0000 1.2
@@ -1,57 +1,70 @@
-
-
-
-acs-reference Design Documentation
-
-acs-reference Design Documentation
-I. Essentials
-
-- There is no user accessible directory
-- There is no sub-site admin accessible diretory
-
-
- Requirements document: Requirements
-
- Data model:?? where does this really go?
-
- ER diagram: None yet
-
-
-II. Introduction
-Reference data is often overlooked in the rush to get coding. In reality, much of ....
-III. Historical Considerations
-Before the existence of acs-reference, the ACS required that you preload some tables in a script to get some basic reference functionality. There were many problems with this:
-
-- No easy way to find out what reference data even existed.
-- No way to find out how old the data was.
-- No way to find out where that data came from.
-- Very US/English slant on the data.
-
- IV. Competitive Analysis
-The only real competition is internally developed solutions.
- V. Design Tradeoffs
-Primary Goals
-
-- This system was designed with maintainability and reusability as its primary goals. By wrapping a layer around all of the reference tables we have increased the maintainability immensely.
-- Another goal was to bring together many different types of data and present them in a logical fashion. It was amazing how little of this data is available on the internet in a database friendly form.
-
-Performance
-When updating the reference tables their is overhead due to the fact that the table is registered with the repository. This should rarely occur anyway as the tables are only added once.
-By not having the actual data itself in the acs-object system, subsequent additions and deletions to the reference tables themselves are unaffected by this overhead.
- VI. API
- VII. Data Model Discussion
- VIII. User Interface
-Their is no end user interface.
-There will
- IX. Configuration/Parameters
-None
- X. Future Improvements/Areas of Likely Change
-A server based update mechanism will be supported. This will allow for tables to be updated (and preferably diffed) instead of being reloaded with a package upgrade.
-An interface to produce xml/csv from the reference data would be a nice service to the community (allowing legacy applications a way to import this data).
- XI. Authors
- XII. Revision History
-
+
+
+
+acs-reference Design Documentation
+
+acs-reference Design Documentation
+I. Essentials
+
+- There is no user accessible directory
+- There is no sub-site admin accessible diretory
+
+
- Requirements document: Requirements
+
+
+II. Introduction
+
+Reference data is often overlooked in the rush to get coding. In reality, much of ....
+
+III. Historical Considerations
+
+Before the existence of acs-reference, the ACS required that you preload some tables in a script to get some basic reference functionality. There were many problems with this:
+
+
+- No easy way to find out what reference data even existed.
+- No way to find out how old the data was.
+- No way to find out where that data came from.
+- Very US/English slant on the data.
+
+ IV. Competitive Analysis
+The only real competition is internally developed solutions.
+
+ V. Design Tradeoffs
+Primary Goals
+
+- This system was designed with maintainability and reusability as its primary goals. By wrapping a layer around all of the reference tables we have increased the maintainability immensely.
+- Another goal was to bring together many different types of data and present them in a logical fashion. It was amazing how little of this data is available on the internet in a database friendly form.
+
+Performance
+When updating the reference tables their is overhead due to the fact that the table is registered with the repository. This should rarely occur anyway as the tables are only added once.
+By not having the actual data itself in the acs-object system, subsequent additions and deletions to the reference tables themselves are unaffected by this overhead.
+ VI. API
+See api-browser
+ VII. Data Model Discussion
+ VIII. User Interface
+Their is no end user interface.
+There needs to be some kind of admin UI to report status and possibly
+manage updates per requirements.
+
+ IX. Configuration/Parameters
+None
+ X. Future Improvements/Areas of Likely Change
+A server based update mechanism will be supported. This will allow for tables to be updated (and preferably diffed) instead of being reloaded with a package upgrade.
+An interface to produce xml/csv from the reference data would be a nice service to the community (allowing legacy applications a way to import this data).
+
+ XI. Authors
+
+Jon Griffin
+
+ XII. Revision History
+
$Log$
+Revision 1.1 2001/04/22 00:53:12 jong
+initial openacs import
+
Revision 1.2 2000/12/13 04:39:00 jong
Added Revision History and corrected typo in reference link
-
-
-
-
+
+
+
+