Mailing List Archive

Hmmm... the problem with the Spinner language, from our point of view,
is that it *doesn't* include the old-style <!--#foo--> directives which
everyone and their dog already has megabytes of.

FYI, there are servers which have extended the <!--#foo--> style
extensively... see

http://www.theworld.com/ssi/ssiplus.htm

for this. (It's from the docs for the WebQuest server, for Windows).

rst

In message <199510061840.OAA05412@volterra.ai.mit.edu>, Robert S. Thau writes:
>Hmmm... the problem with the Spinner language, from our point of view,
>is that it *doesn't* include the old-style <!--#foo--> directives which
>everyone and their dog already has megabytes of.

We have a lot of <!--#foo--> as well, so I'm still supporting that.

The SSI+ language does not look abstract enough (i.e. you do direct comparisons
against USER_AGENT rather than testing abstract properties). I'm also not
enamoured with goto in a preprocessor.

<!--#foo--> has a few advantages over <foo>:

- according to html syntax, you can use '>' as an operator inside <!--#foo-->
since > can appear inside a comment
- it is less likely to conflict with future client-supported tags

On the other hand, <foo> is far easier to type.

Spinner's <if> ... </if> <else> ... </else> is arguably confusing
-- I haven't tried to find out what happens if you insert something
between </if> and <else>. But I think it's less confusing than using
a goto and label scheme.

From my point of view <if> ... <elseif> ... <else> ... </if> would be
least confusing, but doesn't fit into the whole html scheme.

Dean

- it is less likely to conflict with future client-supported tags

...and, at least as importantly, it calls out a server-implemented tag
*as such*, and distinguishes them from the HTML tags at a basic
lexical level. This becomes important if we allow drop-in code to add
new inline commands (a feature which I strongly feel any includes
retread ought to support) for a few reasons:

1) It keeps us, and anybody else writing such extensions, from
conflict with not only the current HTML tag set, but any future
"browser-of-the-month" innovations (<marquee>, etc.), a matter over
which we otherwise have no control. (The current directives
*can't* have such conflicts, since they are now and forever
comments as far as the browsers themselves are concerned).

2) It allows us to note and diagnose the case where someone has tried
to use an include directive which is supported by a server
extension which isn't compiled in --- otherwise, a new random tag
might be intended to trigger new behavior in some random browser,
and we just don't know.

3) It saves us from having to check every single tag to see if
some module supports it as an SSI directive.

(Note that, IMHO, #3 is the least important of these by far, but it
does have a little weight).

One final comment --- <!--#if--> <!--#else--> <!--#endif--> is at
least as SGML-ish as <if> </if> <else> </else> --- more so, IMHO.
It's perfectly fine in SGML to have a tag which is only allowed within
the regions delimited by certain container tags. The form of the end
tag here (<!--#endif-->) is a little peculiar, but the form of all
these things is a little peculiar anyway. The Spinner alternative has
a single region defined by two abutting containers, which is not only
textually but semantically awkward.

rst