From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-27 14:16:43 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.stealth.net!news-east.rr.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com.POSTED!not-for-mail Message-ID: <3B8AB6C8.910130C8@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Progress on AdaOS References: <9IFe7.12813$6R6.1221214@news1.cableinet.net> <9lghqu$ac6$1@nh.pace.co.uk> <3B7C3293.76F49097@home.com> <9lhefg$lgd$1@nh.pace.co.uk> <3B7D47F1.25D6FC78@boeing.com> <5ee5b646.0108171856.18631c4c@posting.google.com> <3B7F624B.7294D24F@acm.org> <9lr6je$5hj$1@nh.pace.co.uk> <9ltoi7$4is$1@nh.pace.co.uk> <3B82789B.8D195045@home.com> <9ltuo8$70n$1@nh.pace.co.uk> <3B829450.879B0396@home.com> <9mdh4e$q3v$1@nh.pace.co.uk> <9me03r$c302@news.cis.okstate.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 27 Aug 2001 21:08:27 GMT NNTP-Posting-Host: 24.165.20.229 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 998946507 24.165.20.229 (Mon, 27 Aug 2001 14:08:27 PDT) NNTP-Posting-Date: Mon, 27 Aug 2001 14:08:27 PDT Xref: archiver1.google.com comp.lang.ada:12491 Date: 2001-08-27T21:08:27+00:00 List-Id: > I was thinking about the metadata article, and my experiances with the > 'raw data' Unix and semi-quasi-metadata Windows. I think the metadata > needs to be hierachial. Actually, my thought about the article was that it was obviously written as a big justification for the idea that the Mac OS shouldn't put file creator types as part of the file name. All the rest of it was either obvious or pointless, or a needless assumption. (IMHO, that is.) For example, it starts off with an assumption that files are named entities, buckets of bits that need interpretation by disassociated program code. This isn't true of "objects" in the OO sense, nor is it true of processes, nor is it true of RPCs. If there were an AdaOS that didn't allow one to declare a passive partition and say "Hey, this is the data", I'd be disappointed. Why *can't* my "file" have a directed acyclic graph of tagged records holding access values in it? > Everything can viewed as raw data. Well, no. Only if you come from the Unix/Windows/CPM world. (Not even there, actually. What's the "raw data" in the superblock? In a directory? In a network-mounted partition?) Those of us who had the privledge of (for example) using ISAM files so you could actually insert a line of text at the beginning of your file without rewriting the whole file can tell you that not everything is raw data. :-) > Then we have > for example, types text, image, video, audio, program, data and > text/utf8, text/utf8/crlf, text/utf8/lf, text/utf8/psls, image/png, > image/tiff, image/tiff/lzw, data/word, data/word/7.0, etc. How about the type for Ada source files? Ada specification headers? Ada bodies? The type for an "Active Server Page" with Ada code embedded in HTML markup under control of CVS? And how do you determine which programs can read such? :-) > So programs > like copy can deal with them on the raw data level, Only in the most primitive of systems does that work. Does copy *really* deal with transfering text files across a TCP link between a unix box and a mac box? No, it's the device drivers. Anyway, I'd think making a persistant Ada-typed store would be a great file system for an Ada-based OS. Then you could have utilities to copy Text_IO-based files to whatever internal format you wanted (such as "editable text"). -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand.