o Placing the link there seems to be a solution to a problem that doesn't exist. The only people currently using the "foo.html" scheme is NeXT, internally. Everyone else is using index.html.
o There's no question that "index.html" is necessary. The ".htmld" files should be as invisible to the user as possible--they should act as much like a plain document as possible. With "index.html," a user can drag the htmld file into a HTTP server directory and make available a URL to it, without having to be aware of its contents.
o If we put a symbolic link in each ".htmld" file, the average user may be presented with 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)
o Remember that a world exists outside of NeXTstep. Copying these files to filesystems not supporting links should be expected. As for the 5-character file extension, should we consider a 3-character alternative, accepting both as the same type? Obviously, we shouldn't let the worry of less fortunate users impede our progress. :) However, I think that including a non-portable concept into a basic filetype definition is a bad idea.
Dan Grillo: I understand your point. However, do you feel the ability to use the "index" file separate from the directory is a real issue? For one, the file is possibly useless/less useful without the information contained within the directory. If an application tried to extract the name of the html file from a URL (for a "Save" or something), it would presumably extract the full "foo.htmld" filename. So the real problem comes down to FTP. We don't usually FTP "rtfd" documents--they're usually in a tar archive. Similarly, we probably won't usually FTP "htmld" documents--they will either be served up via HTTP, or FTPed in a tar archive.
As for the discussion that "htmld" files could contain entire document trees: I agree completely. After all, when you are dealing with hypertext documents, you rarely have only one document to deal with! What better way to encapsulate an entire document tree? In general, I think it would be best if sub-documents also were htmld's. That way, each document's resources are kept associated with it, and the user may easily open up an htmld file and copy out subfiles.
There was some discussion on localization and htmld's. For one, localization is not a concept that HTTP supports, is it? (I always thought that this was a Big Gaping Hole.) Perhaps we should discuss the concepts of localized documents with the Greater Web Community. I agree, though, that our htmld filetype should support localization--for both html files and resources.
In addition, there was some mumbling about keeping multiple resource filetypes around for the same resource (like a foo.eps in addition to a foo.tiff). This is a concept that HTTP supports, although I don't think there is a server that deals with this appropriately. I agree that it is a good idea. However, I am concerned: if we assume that any set of files with the same name but different extensions is the same resource with different types, might we run into problems?
Mike Fleming
<btw: I've never really bothered to use NeXTmail before when not including files...does anyone consider this disruptive/bad/whatever?>