As I've seen it, name.htmld/index.html is going to be the most
portable AND fits the paradigm used by the daemons for an
index.html. If anything else is within the htmld, it should
be a LOGICAL PART of the index.html, whether linked document
contained images, or linked binary image/sound/multi-media...
IF a text vs imagemap version both exist for a document they
generally should share the wrapper.
My question isn't whether more than one .html should be
supported in the wrapper, but if editors should preserve an
index.html that is a ufs soft-link to another file, external
to the wrapper - for read, - for update?
Rohit's suggestion to make index.html the main file within
the wrapper and name.htmld/name.html -> ./index.html looks
the most reasonable to me, not necessarily supported, but
certainly tolerated.
-> In the light of this discussion I propose moving eText to
-> name.htmld/index.html, and scrapping eText's private htmd
-> designation. Sound cool?
Sounds right to me.
Eric Litman posted...
-> b.bum wrote:
-> # For example, say I was doing a page of indexed goo -- a table
-> # of contents, for example -- the TOC would be the index or focus
-> # html document within the htmld, and all the support or content
-> # html would be contained in seperate html files within the htmld
-> # wrapper.
-> I agree with Bill here, with the one modification being that I
-> would like to see htmlds embedded within other htmlds in
-> supplement to individual html documents.
Yes! htmld within htmld NEEDS to be allowable, but multiple
(related) htmls within the same htmld should be fully suported,
with or without separate htmld wrappers.
I'd say that the only restriction on a file within an htmld
is that it should be URL linked from either index.html, or
another html at the same level of htmld wrapper.
Mike Fleming posted:
-> o If we put a symbolic link in each ".htmld" file, the average
-> user may be presented a confusing/annoying "What do I do with
-> this link?" question by the Workspace each time the file is
-> moved. (I suppose you could just use a hard link...ok)
Regarding LOCALIZATION...
ISO-Latin-1 seems to be the default presumed standard.
There's nothing I can see to prevent an httpd from
doing NeXT encoding -> ISO-Latin-1 translation just
as some clients will do the reverse. (mumble mumble
shouldn't there be a keyword in the <head></head> indicating
encoding...)
-> <btw: I've never really bothered to use NeXTmail before when
-> not including files...does anyone consider this disruptive/bad/
-> whatever?>
It's fine with me if it's fine with Unisys :-(
On the other hand, as I read it, this isn't set to be a NEXTSTEP
OpenStep ONLY list.
Regarding ftp (raised by Dan Grillo, and responed to by Mike Fleming)
Won't the wuftpd handle .tar.gz/.tgz on the fly for
directories? Perhaps a standard for ftp access needs to be
defined that ftp URLs for an htmld would ALWAYS point to
an archived version, whether that be .tgz or .zip
-> As for the 5-character file extension, should we consider a
-> 3-character alternative
I'm not at all sure that NeXT would register it, but has anyone
seen .HTD (caps) in use? Unfortunately both .HTM and .HTL are
being used already for .html, seldom translated by DOS servers.
ALSO... a consistent bug in lynx (UKansas text mode browser
client) is to assign ALL download files as .html This seems
to be fixed in the 2.3.7 beta.
Bruce Gingery <bruce@TotSysSoft.com>