Re:HtmlGenerator will improve in next version?

At 2:11 AM 23/8/96, Anselm Baird-Smith wrote:
>Alexandre Rafalovitch writes:
<long and convoluted in my opinion explanation>
>That's a clear explanation, thanks for it. As I said, I believe
>Antonio's SSIResource will cover issue one with more flexibility then
>you can expect (basically you will be able to write new SSI commands
>in Java).
>
I am glad it was understandable.

>With regard to issue 2: as I said, the original plan for jigsaw.html
>was to be a full fledge package probably along the lines that Jeeves
>has (also I haven't look at it closely  yet). Your clarification
>remind me of the original intent of filters. In Jigsaw's first design
>(hum, it was not even call Jigsaw by then ;-) filters were intended to
>provide a way to decorate emitted HTML, one of the goals was to provide
>an nice annotation server (run the server as a proxy that would
>enhance served documents with annotations from a group of people,
>for example). I had forgotten about this one.
>
>With regard to this I would probably go the extreme way (eg use the
>HTML parser that Arthur van Hoff wrote some times ago), and hack it to
>make the structure editable (shouldn't be that hard, although not a
>one hour project).

That would be perfect. I had that idea in my mind myself just did not know
how bloated it is. BTW, tt was hacked once already to remove HotJava
dependancy. You might want to check it at
<http://www.innovation.ch/java/HTTPClient/> That is HTTPClient page, but he
has a local copy of hacked html parser.

>Then you could write the annotation filter, for
>example (?) Although one of the concern with HTML rewriting is that
>it is pretty difficult to be SGM compliant (you don't even know, in
>the case of annotations, if the document to annotate is conformant)

Always a sucker for interesting challenges. :-} Once HTML generator is in
place, I agree  (to try) to write an annotation filter.

> BTW if anyone looks more
>closely into this (eg writes code), then be sure to make your
>generator emit code as soon as possible: one of the trouble with the
>current HtmlGenerator is that it will require you to internally
>generate *all* the document before you can actually send something. If
>the generated doc is to be huge, this is likely to be a real
>problem. (it should be friendly to Piped*Stream for example)

Can you elaborate on this early emit issue. The way I saw it should be,was
actually to keep from emitting code for as long as possible, so all filters
would have a chance to have a go at it. Or do you mean later stage???
If the explanation is long, it might even deserve a separate thread. (eg.
Timing issues in Jigsaw :-} )

Alex.

--------| I feel as confused as a baby in a topless bar. |--------

Received on Thursday, 22 August 1996 21:37:50 UTC