From: Marc Wachowitz
Subject: Why is LOAD-LOGICAL-PATHNAME-TRANSLATIONS in ANSI CL ??? LISPOS people ??
Date:
Message-ID: <645khm$bo7$1@trumpet.uni-mannheim.de>
Rainer Joswig <······@lavielle.com> wrote:
> If the LISPOS people want start, start now with something *simple*. We
> grow from that...
A radical suggestion: Forget all that mess from the application's point
of view: no hosts/devices/etc., only nested names. Use something simple,
like the "pseudo-file-system" name concept of Inferno, and map the ugly
details onto such a logical structure. For some more inspiration, read
http://www.lucent-inferno.com/namespace.html
Provide hooks which allow a "logical file" or "logical directory" to be
implemented (as a kind of very high-level "device driver"), such that e.g.
a "directory" /net may map nested names to network hosts. However, don't
let such a "driver" interact directly with the other layers, but restrict
it to a simple "conceptual file" interface. Avoid deeply interdependent
structures - the full power of OO is likely to fight back in this area.
A "file" is (and remains) first of all a sequence of bytes, which can be
passed/accessed through arbitrary filters (which result in yet another
logical "file") to provide the desired structure. Combine simple tools
- which know how to do one thing very well - with simple means, similar
(in principle, not necessarily in implementation) to Unix pipes/filters.
Above all keep it simple, fight complexity. In practicel, Unix-style
text stream connections - despite all their theoretical "uncleanliness" -
are much more flexible than horribly complex "binary" file structures,
where you can't do much beyond the intentions of the respective application
without lots of low-level programming or special-purpose tools.
Application-typed files are evil. ONE editor is the ultimate "browser", if
only there's an intelligent origanization of the naming system and logical
data structures, with decent (self-)documentation (at that point, Unix
unfortunately lost much for which it did provide a good foundation). Of
course, this doesn't prevent the creation of specific (though most likely
merely customized) menu-directed user interfaces, for those users who
don't want (or shouldn't be able) to manipulate the text structure.
At the application-level, s-expressions are the exchange-format of choice.
With some general conventions, they provide readability, easy parsing
or pretty-printing, and enough room for extensions which can be ignored
by tools which are only interested in a subset of the information. We
may need a kind of concept-oriented SGML based on s-expressions (perhaps
Erik can give some advice in that area?). Maybe XML can be exploited -
I didn't yet look at it very closely, though, and I fear that it might
be (or become) yet another big bag of special cases and low-level hacks.
If you can't use a plain-text-based information structure, use something
more appropriate (like e.g. a self-descriptive relational database, not
necessarily implying the ugliness of SQL and its limitations), but chose
something which is very general, not a myriad of ad-hoc data formats.
This is really only the second-choice, if mere text doesn't work - and
should still use text-based format as contents, where that's reasonable.
-- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>