open issues (to be solved)

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