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,f6f11ace4643916c
X-Google-Attributes: gid103376,public
Path: controlnews3.google.com!postnews1.google.com!not-for-mail
From: martin.dowie@btopenworld.com (Martin Dowie)
Newsgroups: comp.lang.ada
Subject: Re: Ada 2005 presentation at Ada-Belgium event now on-line
Date: 7 May 2004 00:50:21 -0700
Organization: http://groups.google.com
Message-ID: <af783afe.0405062350.3686092b@posting.google.com>
References: <c79042$nvv$1@heli.cs.kuleuven.ac.be>
 <QxUlc.23908$_41.1696225@attbi_s02>
NNTP-Posting-Host: 20.138.254.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1083916222 14595 127.0.0.1 (7 May 2004 07:50:22
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Fri, 7 May 2004 07:50:22 +0000 (UTC)
Xref: controlnews3.google.com comp.lang.ada:349
Date: 2004-05-07T00:50:21-07:00
List-Id: <comp.lang.ada>

tmoran@acm.org wrote in message news:<QxUlc.23908$_41.1696225@attbi_s02>...
> The "tree structured directories" addressed by Ada.Directories are on
> their way out.  Under Windows, for instance, there's a separate directory
> called the Registry (which I understand will disappear in the next major
> release) and there is a (rarely used) additional directory level called
> file resource forks.  It doesn't appear that Ada.Directories applies to
> either of those.  It's also become rather obvious that objects need to be
> "filed" in multiple ways; a single tree is inadequate.  The next version
> of Windows is supposed to address this issue (searching?  relational
> database?).  Ada.Directories will nicely standardize the multiple
> incompatible directory operations packages of today, but that part of
> Ada05 will become obsolete not long after introduction.  IMHO

For Windows probably "yes" and you always have Claw.Registry to use in
that case but for the bulk of embedded work this package will do
nicely. I'm guessing the same is true for Linux/Un*x/VMS but I don't
even have an Ada95 compiler for these.

Just a thought - I don't know the Windows Registry at all but from
what I've seen it is itself a tree structure. Could an implementation
of Ada.Directories (and I guess Ada.Text_IO) wrap the calls to
Claw.Registry? i.e. use A.D to traverse the Registry and A.T to
read/write actual values?

-- Martin