Humbly, I see no reason why Latin-1 has intrisically-recognizable
features. For me it looks the same as floating point, ...
So what? When a user invokes a text editor on a file, she usually
knows which files are text files, and which ones aren't. And even if
she doesn't know, the editor just says "Beep!" or something.
We don't need announcers in the flow of data. Each different animal
must be tagged from the outside with ...
What if I want to email some text to a friend in another country? If
it is to be tagged on the outside, must I send another message with
the tags?
The only other way to treat data if you want to use the
IRV (international reference version of 646) is clearly write,
printable, in the flow of data, what animals these are, in front of
them
This sounds a lot like the new email formats being discussed by IETF.
(and I would suspect you also need length as well: at the moment
you start an ESCAPE sequence so far, even with 2022, unless you have
the latest version of the registry, you're lost in space.
The escape sequences themselves indicate the length of each character,
unless the final character of the escape sequence comes from column 7,
in which case each character can be 4 bytes or more. But even then you
can find the end of the data by looking for the next escape sequence
or simply the end of the data, which is imposed by higher level
protocols, of course.
And if it
appears that the ESC sequence is from a private code, which it is in
most cases, the registry won't help and you're then lost in
hyperspace.
"In most cases"? Do you mean to say that ISO 2022 is widely used
today, particularly with private code?
(in fact the two types of
characters, graphic and control, should also never be intermixed)
If graphic and control characters may not be intermixed, just how do
you intend to send this information down a communications channel,
which sends things bit by bit?
Even Unicode has embedded 16-bit newlines, doesn't it?
If we have a binary file and we really don't know what it is, but
really would like to know, we're in trouble. The IETF is currently
discussing email header formats that would allow sending absolutely
anything in email. What if we simply made each e.g. Unix file take the
form of such an email message? We would need to update various
applications to skip the headers, of course, but the email header
method is very nice in that it is extremely extensible. If you want to
add something new, you just create a new header name. Of course, if
you don't have software that understands such a new header, you're
still in trouble, but at least you can read the header to get some
sort of clue. The Macintosh already "knows" various things about its
files, such as which icon to display, etc. If we put human-readable
(ASCII) headers in Unix files, we can extend Unix files to do the same
thing as the Macs, *and* have a built-in method for a human to find
out roughly what the file is.
I suppose the migration strategy would be to update applications
before you convert the old files that correspond to those
applications. If certain files are shared by many people, you would
have to upgrade all of the copies of the application simultaneously,
but, given some goodwill, I think this should be possible (at least
locally). The kernel would also have to be updated before any binary
executables are given ASCII headers. Etc...
I haven't thought about this for very long, but if this idea can be
used successfully, then what started out as an innocent extension of
Internet email could have far-reaching consequences for the whole Unix
industry.
I'm just joking really. Don't flame too hard! :-)
Cheers,
Erik