# WebKit Future Work

WebKit version 0.9

## Warning

This document hasn't been seriously combed over in some time. It is definitely out of date. You can find better information about known bugs and future work in the Wiki and in the SourceForge tracker systems, both accessible from the Webware Home Page. The SourceForge task manager is currently not used since these systems should be sufficient and we do not want to scatter issues in too many systems.

## Future Work/Limitations

Sprinkled throughout the code are comments tagged with @@ which are hopefully accompanied by a date and someone's initials. These comments represent "TO BE DONE"s. The double at-sign (@@) convention was chosen because it doesn't appear to be used for anything else.

In addition to the inline comments, some significant items have been recorded below. These are future ideas, with no committments or timelines as to when/if they'll be realized. The Python WebKit is open source, so feel free to jump in!

The numbers below are mostly for reference, although longer term items tend to be pushed towards the bottom.

### Known Bugs

1. There is one report that indicates that Application.serverSidePath() may be broken when using MakeAppWorkDir.
2. Contexts do not have separate name spaces.
3. The ListBox example does not take kindly to a Refresh/Reload after a delete operation. In essence, you are telling the ListBox to delete the same object twice.
4. Problems have been reported with cookies on MS IE for the Mac.
5. The OneShot adapter does not clean old sessions when using SessionFileStore.
6. If a context appears in the Contexts setting once by name and once as the default, Application seems to load it twice.

### To Do

1. Major Items
   1. Rearchitect app servers, applications, contexts, etc. One process per application (not several applications per process). Don't worry though. 99% of servlet code will be unaffected by these changes.
   2. CheckSource.py: A program to check the source code conventions.
   3. FormKit: A plug-in to aid the construction and validation of forms. (Already in progress.)
   4. Role-based security and user-authentication. Goal is to eliminate, as much as possible, developer-written security logic. This should be provided by the WebKit and be configurable.
   5. Write a custom adaptor for Apache, Netscape, MS, etc.
   6. Distribution and load balancing.
   7. Fault tolerance.
   8. More sophisticated admin tools including password protection, clearing logs, displaying a maximum of information at a time, etc. Consider using module 'resource'.
   9. Investigate case insensitive URLs, especially for the Windows platform.
   10. Plug-ins
       1. In ExamplePage, automatically support examples of any plug-in
       2. Better docs
       3. Properties.config. 'Load', 0, 1 or the name of the required op sys
2. General
   1. Hunt down: @@ tags (which signify "To Be Done"s), FUTURE items in class doc strings, NotImplementedErrors, -- tags
   2. Code clean up.
   3. Right now, if the Application itself (as opposed to Servlets) throws an exception, it doesn't get captured nicely. However, it is displayed in the app server's console.
   4. The exception handler is pretty nice and has features like logging, e-mail, gathering debugging info, etc. However, on occasions it can throw exceptions too. There should be a simpler, secondary exception handler for when this happens.
   5. Review the timestamp caching logic and its relation to .pyc files if any.
   6. AppServer: Servlets get reloaded when they are changed, but not the Servlets ancestor classes.
   7. Add "Last-modified:" to generic files that are served via WebKit.
   8. If a Python file has only one class that inherits from Servlet, then use that as the Servlet class (rather than requiring the name be the same as the file).
   9. Adopt the code in NewThreadedAppServer as a new model for the ThreadedAppServer.
   10. Adopt the code in serverSideInfoForRequestNewAlgorithm in Application.
   11. Make ThreadeAppServer easily subclassed to allow for customization to AppServer behavior.
3. Testing
   1. Provide testing web page where people can report their testing results including version numbers, etc.
   2. Provide higher level automation of testing. For example, a testing script should be able to launch various app servers multiple times.
   3. Provide highly automated benchmarking so we can track changes in performance.
   4. Expand the regression test suite.
4. Docs
   1. Beef up the User's Guide.
   2. User's Guide: Create a caching section to discuss the virtues of doing so. Color example became 12 X faster on the server side.
   3. Create a tutorial.
   4. Add special Windows instructions in the InstallGuide.
5. Food for thought, considerations, reviews
   1. Consider this statement from the FastCGI docs: Redirects are handled similar to CGI. Location headers with values that begin with "/" are treated as internal-redirects; otherwise, they are treated as external redirects (302).
   2. FastCGI app server: The idea is that if the app server itself supports FastCGI, then it can be used directly with FastCGI enabled web servers sans the infamous "adapter". Dan Green has brought this up in Webware-discuss.
   3. Consider if we need to support <form action="x.py?a=1" method="post"> where you will have both a query string and posted data.
   4. Application modifies sys.path so that servlets can say "from SuperServlet import SuperServlet" where SuperServlet is located in the same directory as the Servlet. We'd prefer a more sophisticated technique which does not modify sys.path and does not affect other servlets. (Or maybe this would go away with a new one-process-per-application architecture.)
6. Check out
   1. Aquarium
   2. http://www.zope.org/Members/Amos/WhatIsAcquisition
   3. http://www.zope.org/Members/jim/Info/IPC8/AcquisitionAlgebra/index.html
   4. http://www.x-works.com
   5. FastCGI related: http://www.tfarmbruster.com/fcgi_sa.htm
7. Down the road
   1. Multi-language support/localization (e.g., vend data to clients in their preferred written language)
   2. Consider CORBA standard RMI-IIOP and it's potential interaction with WebKit. This technology has been marked for inclusion in J2EE. I imagine the idea might be that an app server could be used by more than just web browsers. e.g., it could be used programmatically (in a more natural way than simulating a web client).