- From: Anselm Baird_Smith <abaird@www43.inria.fr>
- Date: Wed, 12 Mar 1997 13:02:01 +0100 (MET)
- To: www-jigsaw@w3.org
Here is a set of open issues, that I am not sure how to solve. These are the places were I know there are still problems, but don't know exactly how to solve it. Any ideas/comments welcome. 1) Indexing model Since 1.0alpha5, I have changed the w3c.jigsaw.indexer package quite a bit (I am not sure I want to commit to these changes though). Instead of having a single indexer (configured through /Admin/Extensions and /Admin/Directories), there is now a catalog of indexers, each indexer has its own set of declared extensions and directories. In each of these there is a special "*default*" entry, to be used if no other match is found. The DirectoryResource has a new attribute "indexer" which gives the name of an indexer to index anything under that resource (in the URL space this time). The advantnage is pretty obvious. For example, you can create a "cgi-indexer", with a "*default*" extension mapped to CgiResource. You can then set the indexer for /cgi-bin to that indexer, and get anything there indexed as a CGI script. By creating a "*default* directory entry set to a DirectoryResource with "indexer"="cgi-indexer", all sub-directories of /cgi-bin will behave as /cgi-bin (ie indexing everything as a script). [more examples deleted] Pretty neat, however... This add complexity to the end user. The indexing model is alreay pretty difficult to unerstand, and I am afraid of making it more complex. I can't sem to be able to find a soltuion to the automatic reindexation of resources when an indexer configuration changes, which is something I would really like to do. I am looking for something like maintaining an indexer last-modified date, which would be check on all resources lookup, and which trigger reindexation before returning if required. 2) Filtering model The filtering model is somhow buggy when it comes to exceptions. It might be the case that a ingoingFilter method is called, withouth aving the outgoingFilter called (if an exception occurs in the perform method of the resource). This leads to a set of problems for filters that set some state in ingoing, and expect to get called at outgoing. The solution may be to have (as was done in client side filters, suggested by Y. Lafon) an exceptionFilter method, the rule being that if your ingoingFilter method is called, at least one of outgoingFilter or exceptionFilter will be called. 3) Request:getOutputStream To implement servlet support, I had to hack something to be able to get the socket output stream (servlets have to be able to write the replies themselves). In order to do that, I have added a fake HTTP status code (w3c.www.http.HTTP.DONE), which notifies the jigsaw engine that the reply for the given request has been emitted. There is also (under certain circumstances), a need for having a resource be able to write the reply straight (ie, typical when a resource generates a very long piece of html, and want to use chunk encoding without having to create a thread). The real problem, however is that it defeats filters that would act on the stream. On solution might be to add a ResourceFilter::getOutputStream(OutputStream) method, which would be called upon Request::getOoutputStream. Eg when Request::getOutputStream is called, it would get the socket output stream, than call all filters getOutputStream methods in sequence, and return that result (this would allow, for example, a compress filter to interleave a GZIPOutputStream in the stream stack). 4) Lookup This is to followup on Joel's mail (check the archive) If you have encountered problems not mentioned in that list, let me know. It is crucial that we get all APIs correct before turning that into beta. Thanks for your attention, Anselm.
Received on Wednesday, 12 March 1997 07:01:59 UTC