# HG changeset patch # User paulb # Date 1114897678 0 # Node ID a6cc8e5f642d002d32820375e224d1375123b2f6 # Parent c04598c3937a744e54b9d7ab15ea60351022673d [project @ 2005-04-30 21:47:58 by paulb] Added more introductory information. diff -r c04598c3937a -r a6cc8e5f642d README.txt --- a/README.txt Sat Apr 30 21:23:30 2005 +0000 +++ b/README.txt Sat Apr 30 21:47:58 2005 +0000 @@ -15,6 +15,19 @@ python tools/demo.py +An introductory guide to creating applications can be found in the docs +directory - see docs/index.html for the start page. + +Contact, Copyright and Licence Information +------------------------------------------ + +The current Web page for WebStack at the time of release is: + +http://www.boddie.org.uk/python/WebStack.html + +Copyright and licence information can be found in the docs directory - see +docs/LICENCE.txt and docs/LICENCE-PyServlet.txt for more information. + Framework Support ----------------- @@ -49,6 +62,8 @@ Standardised deployment for some frameworks (see docs/deploying.html). Introductory documentation in XHTML format. Added server name and port methods to the transaction. +Added a simple demonstration application, incorporating many of the examples +and launched under a single script. New in WebStack 0.8 (Changes since WebStack 0.7) ------------------------------------------------ @@ -71,8 +86,8 @@ Added a method to discover the chosen response stream encoding. Fixed field/parameter retrieval so that path and body fields are distinct, regardless of the framework employed. -Added a method to get a combination of path and body fields (suggested by Jacob -Smullyan). +Added a method to get a combination of path and body fields (suggested by +Jacob Smullyan). Introduced Zope 2 support. Improved Jython/Java Servlet API support (although a special PyServlet class must now be used, and certain libraries must be deployed with applications). @@ -90,8 +105,8 @@ New in WebStack 0.5 (Changes since WebStack 0.4) ------------------------------------------------ -Changed request body fields/parameters so that they are now represented using -Unicode objects rather than plain strings. +Changed request body fields/parameters so that they are now represented +using Unicode objects rather than plain strings. Introduced better support for Unicode in response streams. New in WebStack 0.4 (Changes since WebStack 0.3) @@ -99,8 +114,8 @@ Added application definition of user identity, permitting alternative authentication mechanisms. -Improved BaseHTTPRequestHandler and mod_python reliability around fields from -request bodies. +Improved BaseHTTPRequestHandler and mod_python reliability around fields +from request bodies. Provided stream and environment parameterisation in the CGI adapter. Added LoginRedirect and Login examples. Added get_path_without_query and fixed get_path behaviour. @@ -128,28 +143,30 @@ Things to consider for future releases: improved cookie support, redirects, access to shared resources and much better documentation. -Field access needs testing, especially for anything using the cgi.FieldStorage -class, and the way file uploads are exposed should be reviewed (currently the -meta-data is not exposed). The acquisition of fields from specific sources -should be tested with different request methods - some frameworks provide path -fields in the body fields dictionary, others (eg. Zope) change the fields -exposed depending on request method. +Field access needs testing, especially for anything using the +cgi.FieldStorage class, and the way file uploads are exposed should be +reviewed (currently the meta-data is not exposed). The acquisition of fields +from specific sources should be tested with different request methods - some +frameworks provide path fields in the body fields dictionary, others (eg. +Zope) change the fields exposed depending on request method. -Interpretation of path field encodings needs to be verified. Currently, stray -path fields are handled (eg. in WebStack.Helpers.Request) as being ISO-8859-1, -but it might be the case that some such fields might be submitted as UTF-8. +Interpretation of path field encodings needs to be verified. Currently, +stray path fields are handled (eg. in WebStack.Helpers.Request) as being +ISO-8859-1, but it might be the case that some such fields might be +submitted as UTF-8. Cookie objects need defining strictly, especially since the standard library -Cookie object behaves differently to mod_python (and possibly Webware) Cookie -objects. Moreover, the set_cookie_value method needs to provide access to the -usual cookie parameters as supported by the frameworks. The standard library -Cookie module has issues with Unicode cookie names (and possibly values) - -this is worked around, but it would be best to resolve this comprehensively. +Cookie object behaves differently to mod_python (and possibly Webware) +Cookie objects. Moreover, the set_cookie_value method needs to provide +access to the usual cookie parameters as supported by the frameworks. The +standard library Cookie module has issues with Unicode cookie names (and +possibly values) - this is worked around, but it would be best to resolve +this comprehensively. -UTF-16 (and possibly other encodings) causes problems with HTML form data sent -in POST requests using the application/x-www-form-urlencoded content type. -This should be reviewed at a later date when proper standardisation has taken -place. +UTF-16 (and possibly other encodings) causes problems with HTML form data +sent in POST requests using the application/x-www-form-urlencoded content +type. This should be reviewed at a later date when proper standardisation +has taken place. Session support, especially through WebStack.Helpers.Session, should be reviewed and be made compatible with non-cookie mechanisms. @@ -164,8 +181,8 @@ introduced into WebStack, thus making response output more efficient (and probably also for other frameworks, too). -The algorithm employed in the WebStack.Helpers.Auth.get_token function should -be reviewed and improved for better security. +The algorithm employed in the WebStack.Helpers.Auth.get_token function +should be reviewed and improved for better security. Investigate proper support for HEAD, OPTIONS and other request methods. @@ -194,9 +211,9 @@ Generating the API Documentation -------------------------------- -In order to prepare the API documentation, it is necessary to generate some Web -pages from the Python source code. For this, the epydoc application must be -available on your system. Then, inside the WebStack directory, run the +In order to prepare the API documentation, it is necessary to generate some +Web pages from the Python source code. For this, the epydoc application must +be available on your system. Then, inside the WebStack directory, run the apidocs.sh tool script as follows: ./tools/apidocs.sh