Ada Component Registry proposal

Ada Component Registry proposal

[Robert I. Eachus]

I put together an XML DOCTYPE for a Ada Component Registry, and tried it 
out on GNADE. If anyone who understands XML would like to look at it and 
criticize, I'll send you a copy.  But right now I consider it too 
preliminary to let loose in the wild.  I'll probably have a much better 
worked out version by the end of next week.  (Oops! Mental note to self, 
the registry itself needs a version number. ;-)

I picked GNADE as a test case though, expecting it to be a decent stress 
test.  Boy was it!  For me as well as the XML grammer.  I'd like to 
comment on a few things that I found and what they mean for a formal 
registry, or for the Common Ada Library.

One of the things that the registry does is makes the Zip or tar or 
whatever file that you can download more accessable.  Much more 
accessable.  Amazingly more accessable.  GNADE as delivered has over a 
dozen directories and if you actually compile it, creates a few more. 
(And just to confuse you puts some stuff into existing directories 
outside the GNADE structure.)  With the registry, you can look and see 
that most of the source files are children of GNU.DB, and that package 
declaration can be found in


-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]

do send a copy my way :-).  if you please Robert.

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F92BEAA.9030004@comcast.net...
> I put together an XML DOCTYPE for a Ada Component Registry, and tried it
> out on GNADE. If anyone who understands XML would like to look at it and
> criticize, I'll send you a copy.  But right now I consider it too
> preliminary to let loose in the wild.  I'll probably have a much better
> worked out version by the end of next week.  (Oops! Mental note to self,
> the registry itself needs a version number. ;-)
>
> I picked GNADE as a test case though, expecting it to be a decent stress
> test.  Boy was it!  For me as well as the XML grammer.  I'd like to
> comment on a few things that I found and what they mean for a formal
> registry, or for the Common Ada Library.
>
> One of the things that the registry does is makes the Zip or tar or
> whatever file that you can download more accessable.  Much more
> accessable.  Amazingly more accessable.  GNADE as delivered has over a
> dozen directories and if you actually compile it, creates a few more.
> (And just to confuse you puts some stuff into existing directories
> outside the GNADE structure.)  With the registry, you can look and see
> that most of the source files are children of GNU.DB, and that package
> declaration can be found in
>
>
> -- 
>                                                      Robert I. Eachus
>
> "Quality is the Buddha. Quality is scientific reality. Quality is the
> goal of Art. It remains to work these concepts into a practical,
> down-to-earth context, and for this there is nothing more practical or
> down-to-earth than what I have been talking about all along...the repair
> of an old motorcycle."  -- from Zen and the Art of Motorcycle
> Maintenance by Robert Pirsig
>

Ada Component Registry proposal

[Robert I. Eachus]

  I  put together an XML DOCTYPE for a Ada Component Registry, and tried 
it out on GNADE. If a couple of people who understand XML would like to 
look at it and criticize, I'll send you a copy. But right now I consider 
it too preliminary to let loose in the wild. I'll probably have a much 
better worked out version by the end of next week. (Oops! Mental note to 
self,  the registry itself needs a version number. ;-)

I picked GNADE as a test case though, expecting it to be a decent stress 
 test. Boy was it! For me as well as the XML grammer. I'd like to 
comment on a few things that I found and what they mean for a formal 
registry, or for the Common Ada Library.

One of the things that the registry does is makes the zip or tar or 
 whatever file that you can download more accessable. Much more 
accessable. Amazingly more accessable. GNADE as delivered has over a 
 dozen directories and if you actually compile it, creates a few more. 
(And just to confuse you puts some stuff into existing directories 
outside the GNADE structure.) With the registry, you can look and see 
that most of the source files are children of GNU.DB, and that package 
declaration can be found in ../gnade-src-1.4.3a/support. The problem 
though can be found in that word most.  There is also a separate OCI  
root for an Oracle binding, and over a dozen packages and programs at 
the library level that can conflict with other bindings.  These include 
such wonderful names as Parser, Scanner, SQL, ODBC,  and Tools.

Am I saying that GNADE is horribly organized?  No.  Just that GNADE is a 
excellent example of why a registry is needed.  If there were a standard 
place for a database interface packages--I would prefer 
Interfaces.Xxxxx, but that is a detail--then GNADE could provide some of 
those packages and mix and match with implementations of such packages 
from elsewhere.  And GNU.DB.Support would disappear as GNADE moved to 
using more standard implementations of tables and lists.  Finally, the 
scanner and parser that GNADE provides to support embedded SQL could be 
reused by other projects that have nothing to do with databases.

But all of this has to be understood in terms of encouragement and 
process.  GNADE is not going to adopt major changes just because I say 
they should.  But the existance of a useable registry and "standard" 
Common Ada Library would encourage the GNADE authors to evolve their 
code in directions that will make it easier to reuse.

-- 

                                                    Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the goal of Art. It remains to work these concepts into a practical, down-to-earth context, and for this there is nothing more practical or down-to-earth than what I have been talking about all along...the repair of an old motorcycle."  -- from Zen and the Art of Motorcycle Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[sk]

"Robert I. Eachus" <rieachus@comcast.net>:
 > ... If anyone who understands XML would like to look at ...

Sorry, do not have GNADE nor knowledge of XML. However, I think
that fundamentally you are aiming to establish a naming hierarchy
correct ?

I would prefer to second Warren W. Gay's proposal in the "Standard
Library Interest" thread which suggests, I believe, taking an inventory
of what is already available and integrate it into some acceptable
form.

I am not criticizing your proposal since I have not seen it, but
I feel that inventory and integrate *might* produce more results
and interest in terms of not having to start all over again.

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Robert I. Eachus]

sk wrote:

> I am not criticizing your proposal since I have not seen it, but
> I feel that inventory and integrate *might* produce more results
> and interest in terms of not having to start all over again.

No disagreement.  But doing that inventory is WORK.  A lot of it.  If I 
am going to be doing that work, or even a small part of it, I need 
feedback.  A survey that doesn't include the right information, or is 
not in the right form, is useless.

So at this point my plan is:

1) Design a Registry.

2) Build tools to create it, maintain it and reference it.

3) Populate the Registry.

4) Repeat as needed.

It might be nice to have "official" standard status for the Registry. 
But if it exists and the Registry and supporting tools are widely used, 
it won't matter if it is a de jure or de facto standard.

Having said that I have gotten so far as:

The Registry should be an XML document.

There should be publicly accessable free software that can be used to 
reference the public registry and private or subset registries.  Of 
course, this software should be written in Ada, and be listed in the 
Registry. ;-)

For this to work, the registry is going to require lots of feedback.  As 
I said, for now I just want to send the very preliminary draft to people 
willing to read it as XML.  Soon I should have the XML solid enough to 
write a quick XML to HTML converter, and I can post the draft registry 
in html form also.  After that will come a database form with query 
tools.  But notice that the "reference" form of the registry will be an 
XML document, even if the normal use of it is to update a local database.

To misuse a great quote from Larry Niven and Jerry Pournelle's Oath of 
Fealty:  "Think of it as evolution in action."  The whole idea is to 
create a process that makes reuse of Ada easier.  Evolution of the 
contents of the registry, the registry, and the registry toolset all 
need to be part of that process.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[sk]

I would like to propose "Ada95" as the root of the library
hierarchy.

Many Ada projects have a common name such as (my own stuff)
EduOS-Ada, or GtkAda or <normal-name>+<"Ada"> which always
suggests that "Ada" is "special" with all the negative conotations.

I believe (note the singular pronoun *I*, a sample set of 1 :-)
that some people, including myself, are put off by this seemingly
egotistical naming convention that the Ada community seems to follow.

So GtkAda -> Ada95.Gtk etc.
... AdaSockets -> Ada95.Sockets
etc.

This naming convention could also be used to happily distinguish
between code strictly for '83, '95 and '0y

Ada83.Gtk, Ada83.SDL, Ada83.Sockets etc.
Ada95.Gtk, Ada95.SDL, Ada95.Sockets etc.
Ada0y.Gtk, Ada0y.SDL, Ada0y.Sockets etc.

with of course the possibilities of renaming etc.

package Ada95.Sockets renames Ada83.Sockets;
package Ada0y.Sockets renames Ada83.Sockets;

as an example.

I am not trying in any way to usurp RI Eachus' effort, I am
just trying to keep the ball rolling whilst he is formalizing.

There seems to be a lot of momentum at the moment for defining
and creating a common/standard library and I want to keep it going.

With the idea of keeping the momentum going, I am willing to
volunteer a start at doing some of the inventory work to meet
RI Eachus' proposal and as per any discussion that this message
invokes..

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Robert I. Eachus]

sk wrote:
> I would like to propose "Ada95" as the root of the library
> hierarchy.

I think we should be aiming for the future, not the past.

> This naming convention could also be used to happily distinguish
> between code strictly for '83, '95 and '0y
> 
> Ada83.Gtk, Ada83.SDL, Ada83.Sockets etc.
> Ada95.Gtk, Ada95.SDL, Ada95.Sockets etc.
> Ada0y.Gtk, Ada0y.SDL, Ada0y.Sockets etc.

What about Ada80.Sockets, Ada87.Sockets, and Ada2000.Sockets?

The differences between some of these versions, and others not mentioned 
is slight.  (For example, there were three differences between MIL-STD 
1815A, and ANSI/MIL-STD 1815A, and the second was the page number for 
2-2. ;-)  But the current standard really is Ada 2000, although its 
formal name is more cumbersome.  It is possible to get a copy of TC1 and 
see what changed between Ada 95 and Ada 2000, but I prefer to just use 
the standard as posted at: http://www.ada-auth.org/~acats/arm.html

To quote from that page: "When ISO published the Technical Corrigendum, 
it did not also publish a document that merges the Technical Corrigendum 
changes into the text of the International Standard. However, ISO rules 
require that the project editor for the Technical Corrigendum be able to 
produce such a document on demand. The document available here is what 
the project editor would provide to ISO in response to such a request. 
It should be understood that the publication of any ISO document 
involves changes in "boilerplate" as well as a review by professional 
editors that may introduce editorial changes."

I'm not trying to be a stickler for accuracy here, just pointing out 
that the Ada standard is evolving.  I'd hate to have the CAL come out 
labelled as Ada95 (or Ada2000) just in time for the Ada 0X standard.

> I am not trying in any way to usurp RI Eachus' effort, I am
> just trying to keep the ball rolling whilst he is formalizing.
> 
> There seems to be a lot of momentum at the moment for defining
> and creating a common/standard library and I want to keep it going.
> 
> With the idea of keeping the momentum going, I am willing to
> volunteer a start at doing some of the inventory work to meet
> RI Eachus' proposal and as per any discussion that this message
> invokes..

I'll be calling soon. ;-)  But right now I could use a couple more 
people who know XML to do some reviewing.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[sk]

"Robert I. Eachus" <rieachus@comcast.net>:
 > What about Ada80.Sockets, Ada87.Sockets, and Ada2000.Sockets?
 >
 > The differences between some of these versions, and others not
 > mentioned is slight. (For example, there were three differences
 > between MIL-STD ...

Interesting, I must look at my LRM (after I find it) to see whether I
followed MIL-STD or ANSI/MIL-STD Ada'83 :-) This also might explain a
recent problem of ARM quoting where myself and another where quoting
from the same textual section/paragraph but were using different chapter
numbers. However, I don't see this as particularly limiting.

Another reason I would prefer a short and complete name, such as Ada95
is that "CAL", "SAL", "XAL", "EACHUS" etc. don't suggest what they are
and they are acronyms or peoples personal labels rather than being
descriptive etc.

 > I'm not trying to be a stickler for accuracy here, just pointing out
 > that the Ada standard is evolving.  I'd hate to have the CAL come out
 > labelled as Ada95 (or Ada2000) just in time for the Ada 0X standard.

Yes, but the inventory would be for *now* which is for Ada95 and prior,
when sub-packages become suitable for Ada0x, then they move to the Ada0x
tree. Not picking, just do not see the difficulty.

I am not fighting for my own idea, just trying to steer away from acronyms,
personal labels, or corporate hierarchy names (GNAT.Directory_Operations, 
nothing against GNAT, but do not know how it will port to a platform not
supported by GNAT).

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3211 bytes --]

Well I'm reviewing it right now :-).  Have you taken a decision on where
you'd be putting the copyright as we discussed in emails?

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F95FB78.4090305@comcast.net...
> sk wrote:
> > I would like to propose "Ada95" as the root of the library
> > hierarchy.
>
> I think we should be aiming for the future, not the past.
>
> > This naming convention could also be used to happily distinguish
> > between code strictly for '83, '95 and '0y
> >
> > Ada83.Gtk, Ada83.SDL, Ada83.Sockets etc.
> > Ada95.Gtk, Ada95.SDL, Ada95.Sockets etc.
> > Ada0y.Gtk, Ada0y.SDL, Ada0y.Sockets etc.
>
> What about Ada80.Sockets, Ada87.Sockets, and Ada2000.Sockets?
>
> The differences between some of these versions, and others not mentioned
> is slight.  (For example, there were three differences between MIL-STD
> 1815A, and ANSI/MIL-STD 1815A, and the second was the page number for
> 2-2. ;-)  But the current standard really is Ada 2000, although its
> formal name is more cumbersome.  It is possible to get a copy of TC1 and
> see what changed between Ada 95 and Ada 2000, but I prefer to just use
> the standard as posted at: http://www.ada-auth.org/~acats/arm.html
>
> To quote from that page: "When ISO published the Technical Corrigendum,
> it did not also publish a document that merges the Technical Corrigendum
> changes into the text of the International Standard. However, ISO rules
> require that the project editor for the Technical Corrigendum be able to
> produce such a document on demand. The document available here is what
> the project editor would provide to ISO in response to such a request.
> It should be understood that the publication of any ISO document
> involves changes in "boilerplate" as well as a review by professional
> editors that may introduce editorial changes."
>
> I'm not trying to be a stickler for accuracy here, just pointing out
> that the Ada standard is evolving.  I'd hate to have the CAL come out
> labelled as Ada95 (or Ada2000) just in time for the Ada 0X standard.
>
> > I am not trying in any way to usurp RI Eachus' effort, I am
> > just trying to keep the ball rolling whilst he is formalizing.
> >
> > There seems to be a lot of momentum at the moment for defining
> > and creating a common/standard library and I want to keep it going.
> >
> > With the idea of keeping the momentum going, I am willing to
> > volunteer a start at doing some of the inventory work to meet
> > RI Eachus' proposal and as per any discussion that this message
> > invokes..
>
> I'll be calling soon. ;-)  But right now I could use a couple more
> people who know XML to do some reviewing.
>
> -- 
>                                                      Robert I. Eachus
>
> "Quality is the Buddha. Quality is scientific reality. Quality is the
> goal of Art. It remains to work these concepts into a practical,
> down-to-earth context, and for this there is nothing more practical or
> down-to-earth than what I have been talking about all along...the repair
> of an old motorcycle."  -- from Zen and the Art of Motorcycle
> Maintenance by Robert Pirsig
>

Re: Ada Component Registry proposal

[Jeff C,]

"sk" <noname@myob.com> wrote in message
news:mailman.162.1066796252.25614.comp.lang.ada@ada-france.org...
> "Robert I. Eachus" <rieachus@comcast.net>:
>  > What about Ada80.Sockets, Ada87.Sockets, and Ada2000.Sockets?
>  >
>  > The differences between some of these versions, and others not
>  > mentioned is slight. (For example, there were three differences
>  > between MIL-STD ...
>
> Interesting, I must look at my LRM (after I find it) to see whether I
> followed MIL-STD or ANSI/MIL-STD Ada'83 :-) This also might explain a
> recent problem of ARM quoting where myself and another where quoting
> from the same textual section/paragraph but were using different chapter
> numbers. However, I don't see this as particularly limiting.
>
> Another reason I would prefer a short and complete name, such as Ada95
> is that "CAL", "SAL", "XAL", "EACHUS" etc. don't suggest what they are
> and they are acronyms or peoples personal labels rather than being
> descriptive etc.
>
>  > I'm not trying to be a stickler for accuracy here, just pointing out
>  > that the Ada standard is evolving.  I'd hate to have the CAL come out
>  > labelled as Ada95 (or Ada2000) just in time for the Ada 0X standard.
>
> Yes, but the inventory would be for *now* which is for Ada95 and prior,
> when sub-packages become suitable for Ada0x, then they move to the Ada0x
> tree. Not picking, just do not see the difficulty.

I think this is not the right path. When Ada 2020 comes out and we want to
add a new
subprogram to Ada05.Directory_Operations does that mean we now have an
Ada20.Directory_Operations
that looks the same but with the new procedure or do we add to it. No matter
what the answer is I don't think I
like it.

Re: Ada Component Registry proposal

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

"Jeff C," <nolongersafeto@userealemailsniff.com> wrote in message
news:uEtlb.204590$%h1.203097@sccrnsc02...
>
> I think this is not the right path. When Ada 2020 comes out and we want to
> add a new
> subprogram to Ada05.Directory_Operations does that mean we now have an
> Ada20.Directory_Operations
> that looks the same but with the new procedure or do we add to it. No
matter
> what the answer is I don't think I
> like it.
>
*** I agree, although I dont think it's that bad an idea, but Jeff is right,
the library shouldn't reflect what was used to develop it because it will
follow through Ada's evolution.  An independant name like CAL or any other
for that matter would isolate the library from the language thus making the
motion from what version of Ada to the next seamless :-).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Ada Component Registry proposal

[sk]

nolongersafeto@userealemailsniff.com:

 > I think this is not the right path. When Ada 2020 comes out and
 > we want to add a new subprogram to Ada05.Directory_Operations
 > does that mean we now have an Ada20.Directory_Operations that looks
 > the same but with the new procedure or do we add to it. No matter
 > what the answer is I don't think I like it.

The Ada83, Ada95, Ada0x scheme was intended to imply a "works-with"
relationship rather than a versioning relationship.

For example, there is a good chance that an Ada83.Directory_Operations
would resort to the subprogram'address methods for binding whereas
the Ada95.Directory_Operations would take advantage of the Interfaces.*
hierarchy and also possibly the subprogram'access capability of Ada'95.

I think the issue you describe tends to be a versioning issue rather
than a library-hierarchy issue and would occurr whether the root name
for the library was "root", "Ada95" or "CAL".

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[sk]

stephane.richard@verizon.net:
 > the library shouldn't reflect what was used to develop it
 > because it will what was used to develop it because it will
 > follow through Ada's evolution

I disagree, not with your naming disagreement since I have
absolutely no vested interest one way or another, but I disagree
with the idea that it shouldn't "reflect what was used to develop it".

If you have libraries hanging around for Ada83, you need to be
very aware that Ada83 techniques were used to develop it. Admittedly,
if you are compiling from source, this would rapidly become apparent
but there is a need to know which version of Ada the code was
intended to work with.

The naming scheme would give an immediate signal that there are
potentially very dangerous 'Address clauses and UC's going on in
the body which are totally uneccessary with Ada95.

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Marin David Condic]

I'd bet you wouldn't want to make everyone change their code if a new 
version of the library were to come out. Not unless you'd freeze "Adaxx" 
and add only new stuff to "Adayy" - and I think that would end up an 
unholy mess.

MDC

Robert I. Eachus wrote:
> 
> What about Ada80.Sockets, Ada87.Sockets, and Ada2000.Sockets?
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Ada Component Registry proposal

[sk]

MDC :
 > Not unless you'd freeze "Adaxx" and add only new stuff to
 > "Adayy" - and I ...

Again I am not going to argue for "Adaxx" and as I have said,
I have no vested interest one way or another and the idea was
not intended as a version control.

 From RI Eachus' discussion concerning the standards, and the
statement "But the current standard really is Ada 2000,", it
would suggest that the current "Ada.*", "Interfaces.*" etc are
not frozen either and there is absolutely nothing to prevent
vendors from silently implementing an AI update.

I am *almost* tempted to do "diffs" on all of the GNAT supplied
"Ada.*", "Interfaces.*" for 3,13p and 3.15p, both of which are
for Ada'95, to see if there are specification changes to meet AI
requirements.

... and again, this issue would occurr no matter what the "root"
package was called.

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Robert I. Eachus]

Stephane Richard wrote:
> Well I'm reviewing it right now :-).  Have you taken a decision on where
> you'd be putting the copyright as we discussed in emails?

I think the right answer is in both the project description and the 
individual name entries.  Probably make it an optional section in both 
places.  Hmmm.  Maybe better is that it is required for the project, 
even if all it says is "Varies, see components."

I'm also thinking deeply about what you said vis-a-vis uncgi.  Maybe the 
best thing to do is just write a cgi-bin program in Ada, and if 
necessary, convert some of the uncgi routines to Ada to avoid any 
inherent buffer overflow problems.  That would allow me to make the 
actual query screen pure HTML that runs the cgi-bin program to do 
selections.  Of course, for now all I plan is an XML to HTML converter 
that will allow the entire registry to be viewed as pure HTML.

-- 
                                            Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]

that makes sense to me and that can be done :-).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F96B6F9.3040302@comcast.net...
> Stephane Richard wrote:
> > Well I'm reviewing it right now :-).  Have you taken a decision on where
> > you'd be putting the copyright as we discussed in emails?
>
> I think the right answer is in both the project description and the
> individual name entries.  Probably make it an optional section in both
> places.  Hmmm.  Maybe better is that it is required for the project,
> even if all it says is "Varies, see components."
>
> I'm also thinking deeply about what you said vis-a-vis uncgi.  Maybe the
> best thing to do is just write a cgi-bin program in Ada, and if
> necessary, convert some of the uncgi routines to Ada to avoid any
> inherent buffer overflow problems.  That would allow me to make the
> actual query screen pure HTML that runs the cgi-bin program to do
> selections.  Of course, for now all I plan is an XML to HTML converter
> that will allow the entire registry to be viewed as pure HTML.
>
> -- 
>                                             Robert I. Eachus
>
> "Quality is the Buddha. Quality is scientific reality. Quality is the
> goal of Art. It remains to work these concepts into a practical,
> down-to-earth context, and for this there is nothing more practical or
> down-to-earth than what I have been talking about all along...the repair
> of an old motorcycle."  -- from Zen and the Art of Motorcycle
> Maintenance by Robert Pirsig
>

Re: Ada Component Registry proposal

[Robert I. Eachus]

sk wrote:

> The naming scheme would give an immediate signal that there are
> potentially very dangerous 'Address clauses and UC's going on in
> the body which are totally uneccessary with Ada95.

Right now the XML grammer has a requires clause that can specify 
libraries, hardware, operating systems, and compilers.  Adding a 
language version requirement as such is trivial.

But again, and this is why I am still at the thinking stage, right now 
if you "require" two different hardware platforms or operating systems, 
there is an implicit "or", while two software libraries have an implicit 
"and".  It may be worth making those explicit, or it might be better to 
have a supports clause.  That way supports Ada 95 and Ada 83 implies it 
has been tested on both, while requires Ada 95 implies it doesn't work 
under Ada 83.  And of course, requires for a particular compiler would 
be much more restrictive in meaning that supports that compiler.  What 
do you think?

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[sk]

"Robert I. Eachus" <rieachus@comcast.net>:

 > Right now the XML ...
 > ... <snip> ...
 > under Ada 83.  And ...

Firstly, I am not too sure about how realistic the scenario of
having both Ada83 and Ada95 libraries co-residing in the same
development environment is. It was just an example of things that
need to be thought of.

My very limited exposure to cross-compiling on Linux suggests
that 2 completely separate libraries are maintained even if the
vast majority of the code is the same.

What do I think ? I don't think I understand all the implications
of what you are saying since I don't understand XML or have GNADE
installed :-)

However, since I am foaming at the brain for something, here are my
thoughts from march this year

NOTE: I am not a big fan of expanding the "Ada.*" or "Interfaces.*"
hierarchies. The "Ada.Strings.*" packages seem "alien" to me as
part of the ARM hierarchy and really should be (*my* opinion) in
the conceptual new package hierarchy. Limit the ARM hierarchy as
I quote Larry Killigan suggesting in one of the following messages.


-- 2003-05-03 Re: Ada2005 clear scressn etc. ----------------------
 > Hi,
 >
 > <randhol+news@pvv.org> :
 > > As a external library. I don't see the need for it. I mean next
 > > will be that we should have some sort of GUI standard in the
 > > Ada standard.
 >
 > In case anybody is starting a voting process on this, I am in the
 > <randhol+news@pvv.org> group of hoping that specific platform needs
 > are NOT incorporated into any new language standards.
 >
 > Let the market decide on useful *external* libraries, but do not
 > burden the language itself with items possibly subject to fashion
 > or politics.
 >
 > Eg, Sockets : Windows has an API for sockets, the rest of the world
 > has another. I would not like for Ada, a few years from now, tied
 > to the obsolete socket API when the politics gets sorted out and
 > one API is accepted by all. Also especially since the abstract concept
 > of "sockets" might have changed altogther and be called "connection" or
 > "channel" or something.

-- 2003-06-03 Re: Ada2005 clear scressn etc. ----------------------
 > Hi,
 >
 > Stephen.A.Leake@nasa.gov :
 > > ... ANSI standard ...
 >
 > I was more panicing over the thought that the language
 > be bound to some possibly transient fashion and hadn't
 > stopped to consider some never dying, ubiquitous things
 > like the ANSI terminal standard.
 >
 > However, I tend towards the <Kilgallen@SpamCop.net> comment
 >
 > > Because the Ada standard should be for things that require
 > > support from the compiler vendor.
 >
 > and subsequent comments on the response cycle for a set of
 > libraries.
 >
 > With that thought, how about an official but very flexible
 > and distinctly separate package hierarchy ?
 >
 > (.. and I am sure it has been discussed before or there are
 > comments as part of the Ada200y process, sorry for lack of
 > opportunity to fully investigate. Also please note that I
 > am not familiar with any of the ongoing Ada library projects
 > or the "C++" standard library so, again, sorry if this is
 > a rehash of other discussions or duplication of ideas so
 > RTFM me, with URL, if appropriate).
 >
 > Standard
 >     Ada.xxx
 >     Interfaces.xxx
 >     System.xxx
 >
 >     Libraries.xxx
 >
 > "Libraries" just a graft point, nothing significant about
 > the name. "Libraries" would, by agreement, have some invarient
 > subtrees. Perhaps two levels of abstract/conceptual packages
 > before specific solutions are grafted into the tree ?
 >
 > Libraries.Vendor (invarient, children as needed)
 >     .Gnat.
 >         .Os_Lib;
 >     ...
 >     .RRSoftware
 >         .Claw
 >     ...
 >
 > Libraries.Host (invariant, children as needed)
 >     .Linux
 >     .Windows
 >         .Win32Ada
 >
 > Libraries.Host_Interfaces.
 >     .Console.
 >         .ANSI_Terminal
 >             <Perhaps the M.Feldman terminal package >
 >         .VT100_Terminal
 >         ...
 >     .Graphical
 >         .Win32Ada renames Libraries.Host.Windows.Win32Ada
 >         .GtkAda
 >         ...
 >     .File_System
 >         ...
 >     .Network
 >         .Transport
 >             .Sockets
 >             ...
 >         .Protocols
 >             .Smtp
 >             .Http
 >             ...
 >     .etc
 >
 > Libraries.Objects_And_Methods
 >      .Containers
 >          . <The current Container library project perhaps>
 >
 >      .Strings
 >          <Just "Ada.Strings.*" as an example of the purpose
 >           for "Libraries.Objects_And_Methods">
 >
 > Libraries.Standardized_Interfaces
 >      .Posix
 >      .RFCs
 >
 > etc
 >
 > There are a lot of crossovers, but Ada has the "renames"
 > mechanism which could associate "Libraries.Vendor.Gnat.Directory_Operations"
 > for example,
 > with "Libraries.Host_Interfaces.File_System.Directories"
 >
 > This needs a lot more thought and work (rearrangment, better
 > nameing, interdependencies, circularity, management burden etc),
 > however, it could provide a more cohesive framework into which
 > APIs would fit without burdening the core language or its "Ada.*"
 > package hierarchy.
-----------------------------------------------------------------------



-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:
:   Of course, for now all I plan is an XML to HTML converter 
: that will allow the entire registry to be viewed as pure HTML.

Uhm, I think there are some choices, I hope I'm not just
stating the obvious:

a/ use an XSLT.
 a1/  use that directly in the browser, via a
      <?xml-stylesheet ...?> processing instruction
 a2/  run it once, result is "static" HTML.

b/ use CSS 2 with XML, current browsers can display XML content with
   the help of CSSs
   (however, CSS 2 does not allow one to make element selections etc)

c/ combine them

Are you thinking of a2, using some DTD for the registry documents?

I've set up a dummy text using DocBook (not because I think it
is well suited, but because everything is readily available,
including XSL transformations.) Its structure and content
do not reflect the registry except making stupid references to the
context, for the sake of an example. It shows that (a1) does
not yet work too well; (a1) does work to some extent if you have the XSLT
in local files, at least with Mozilla.

With no fancy style; the "data content" is in test.xml,

http://home.arcor.de/bauhaus/tmp.Ada/test.html  (a2)
http://home.arcor.de/bauhaus/tmp.Ada/test.pdf  (a2', PDF, same procedure) 
http://home.arcor.de/bauhaus/tmp.Ada/test.xml  (original XML file)
http://home.arcor.de/bauhaus/tmp.Ada/test-local.xml
(local XSLT, type="text/xsl", not type="application/xslt+xml")

Done using DocBook XSL stylesheets 1.62.4, a copy of the HTML part
is referenced in the processing instruction in test.xml.


Georg

Re: Ada Component Registry proposal

[Robert I. Eachus]

sk wrote:

> However, since I am foaming at the brain for something, here are my
> thoughts from march this year
...
>  >     Libraries.xxx
>  >
>  > "Libraries" just a graft point, nothing significant about
>  > the name. "Libraries" would, by agreement, have some invarient
>  > subtrees. Perhaps two levels of abstract/conceptual packages
>  > before specific solutions are grafted into the tree ?
>  >

As good as any other...

>  > Libraries.Vendor (invarient, children as needed)
>  >     .Gnat.
>  >         .Os_Lib;
>  >     ...
>  >     .RRSoftware
>  >         .Claw
>  >     ...
>  >
>  > Libraries.Host (invariant, children as needed)
>  >     .Linux
>  >     .Windows
>  >         .Win32Ada...

More a style comment than anything else, I think this hierarchy is not 
bushy enough to be natural for Ada.  For example, above I would prefer:

Libraries.Gnat.
Libraries.Claw
Libraries.Linux
Libraries.Windows

As the second level entries.  We are all big boys and girls who know how 
  to use grep, or the equivalent if we need to do a search.  It might be 
worth having OS as a second level, but only if it didn't push things 
toward a renames.  How about:

Libs.OS.Linux
Libs.OS.Windows...

Of course, resolving this is important. But as far as the registry 
project goes, I need to register what exists now.

-- 
                                              Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[sk]

rieachus@comcast.net:
 > ... I would prefer:
 >
 > Libraries.Gnat.
 > Libraries.Claw
 > Libraries.Linux
 > Libraries.Windows

Personally, I would prefer conceptual, "OS", "Network", "Vendor" at
the second level but I also see that this can become very messy. I
did like the idea of the tree that was the R1000 environment but at
the same time, it became a pain trying to remember where everything
was.

 > Libs. ...
Everyone knows that "Libs" means "Libraries" but the shortened form
bugs me like acronyms do, anal retentive I know, but why not spell
every thing out ?

 > ... I need to register what exists now.

Ah, I was under the impression from the other thread that you were
proposing a formal approach before collecting data. Admittedly, I
have been having more fun trying to bait Russ, but it seems as if the
other thread has become a discussion between MDCondic and WGGay over
how to put a library together, either highly competitive or highly
cooperative.

Regardless, I posted my thoughts to see how others felt and I am
not too concerned (not zealous) about any of my issues as long as
the process has a certain level of open discussion.


 > ... I need to register what exists now.

... and from a previous post  ...

 > I think we should be aiming for the future, not the past.

Not XOR but there seems to be a certain OR about the two statements :-)

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[sk]

me:
 > certain level of open discussion.

I need to highlight *open* and I must confess some discomfort
over the implications of another message of this thread

rieachus@comcast.net:
 > Stephane Richard wrote:
 > > ... copyright as we discussed in emails?
 >
 > I think  ...


-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Robert I. Eachus]

sk wrote:

>  > ... I need to register what exists now.
> 
> ... and from a previous post  ...
> 
>  > I think we should be aiming for the future, not the past.
> 
> Not XOR but there seems to be a certain OR about the two statements :-)

Exactly.  Marins want to find a better way to determine what user 
requirements for a standard library are.  I think that the registry will 
eventually turn into a resource that indicates what actually exists now 
(or at some point in the future) and what of that is used.  Then others 
will be able to take this set and evolve it toward a consistant library.

I certainly have no objection to a "standard" library that comes in 
pieces supplied by different authors and groups and where one of the 
things that the standard library provides is "fixed points" where all of 
the components have been synchronized so that there is no version skew. 
  Users can then take one or more later versions of particular 
components, but will have to be aware of the potential version skew 
problems.

-- 
                                           Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[Robert I. Eachus]

sk wrote:
> me:
>  > certain level of open discussion.
> 
> I need to highlight *open* and I must confess some discomfort
> over the implications of another message of this thread
> 
> rieachus@comcast.net:
>  > Stephane Richard wrote:
>  > > ... copyright as we discussed in emails?
>  >
>  > I think  ...

Don't worry about it.  I said that I thought that the first version of 
the XML document was not something I would be comfortable posting, but I 
would send copies to anyone who wanted to review it.  Stephane Richard 
was willing to do so.  Unless there are significant changes, or more 
people who want to take a shot at the current XML state, I will probably 
post version 0.2 to comp.lang.ada tomorrow.  Another potential delay is 
that I am probably going to write an XML to HTML converter this weekend, 
so you can look at the HTML to make comments.

No intent to exclude anyone, but XML is still not all that common a 
language, and I felt the intersection of those who knew XML well enough 
to comment, and were also interested in the registry project would be 
pretty small.  Hmmm.  Actually, why not?  Here is the current XML 
DOCTYPE, and the start of the registry declaration.  If you want a 
snapshot of the whole thing, send e-mail.  But, please, only if you are 
willing to read it and comment.:

<?xml version="1.0" encoding="UTF-8" standalone=yes ?>
<!DOCTYPE Ada_Component_Registry [
<!-- Version 0.2 Doctype Copyright 2003 by Robert I. Eachus, copying 
allowed, all other rights reserved for now. -->
   <!ELEMENT Registry (Author*, Project+, Entry+) >
   <!ATTLIST Registry
       Name         CDATA  #REQUIRED
       Version      CDATA  #REQUIRED
       Website      CDATA  #IMPLIED
       Copyright    CDATA  #REQUIRED
   >
   <!ELEMENT Project (Author*, Requires*, Supports*, Description?)
   <!ATTLIST Project
       Name         CDATA  #REQUIRED
       Version      CDATA  #IMPLIED
       Website      CDATA  #IMPLIED
       Bug_Reports  CDATA  #REQUIRED
       Copyright    CDATA  #REQUIRED
   >
   <!ELEMENT Entry (Author+, Description?, Requires*, Supports*, 
Contents?)
   <!ATTLIST Entry
       Name      CDATA  #REQUIRED
       Project   CDATA  #REQUIRED
       Version   CDATA  #IMPLIED
       Source    CDATA  #IMPLIED
       Copyright CDATA  #IMPLIED
   >
   <!ELEMENT Author>
   <!ATTLIST Author
       Name      CDATA  #REQUIRED
       Email     CDATA  #IMPLIED
       Telephone CDATA  #IMPLIED
       Company   CDATA  #IMPLIED
       Address   CDATA  #IMPLIED
   >
   <!ELEMENT Compiler >
   <!ATTLIST Compiler
             Name    CDATA   #REQUIRED
             Version CDATA   #IMPLIED
   >
   <!ELEMENT Contents (#PCDATA )>
   <!ELEMENT Database>
   <!ATTLIST Database
             Name    CDATA   #REQUIRED
             Version CDATA   #IMPLIED
   >
   <!ELEMENT Date (((Month, Day?)?, Year)|#PCDATA)>
   <!ELEMENT Description (#PCDATA )>
   <!ELEMENT Full_Name (#PCDATA )>
   <!ELEMENT Language
   <!ATTLIST Language
             Version (Ada80 | Ada83 | Ada95 | Ada2000 | Ada0X) "Ada95"
   <!ELEMENT OS>
   <!ATTLIST OS
             Name    CDATA   #REQUIRED
             Version CDATA   #IMPLIED
   >
   <!ELEMENT Project_Name (#PCDATA ) >
   <!ELEMENT Requires (Project_Name|Compiler|OS|Hardware)+ >
   <!ELEMENT Supports (Language_Version|Compiler|OS|Hardware)+ >
   <!ELEMENT Root_Name (#PCDATA )>
   <!ELEMENT URL (#PCDATA ) >
   <!ELEMENT Version (#PCDATA)>
   <!ATTLIST Version Date CDATA >
   <!ELEMENT Website (#PCDATA) >
]>

   <Registry Name="Ada Component Registry"
             Version="0.2"
             Copyright="Copyright 2003 by Robert I. Eachus, copying 
allowed, all other rights reserved for now."
   >

-- 
                                             Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[Robert C. Leif]

    
    Why are you using a DTD, which is the antithesis of Ada? A schema which
is the semantic equivalent (translation) of a collection of Ada types would
be far more appropriate. 
    Bob Leif
    Robert C. Leif, Ph.D.
    Email rleif@rleif.com
    ------------------------------------------------
    Robert I. Eachus Wrote:
    
    Don't worry about it.  I said that I thought that the first version of 
    the XML document was not something I would be comfortable posting, but I

    would send copies to anyone who wanted to review it.  Stephane Richard 
    was willing to do so.  Unless there are significant changes, or more 
    people who want to take a shot at the current XML state, I will probably

    post version 0.2 to comp.lang.ada tomorrow.  Another potential delay is 
    that I am probably going to write an XML to HTML converter this weekend,

    so you can look at the HTML to make comments.
    
    No intent to exclude anyone, but XML is still not all that common a 
    language, and I felt the intersection of those who knew XML well enough 
    to comment, and were also interested in the registry project would be 
    pretty small.  Hmmm.  Actually, why not?  Here is the current XML 
    DOCTYPE, and the start of the registry declaration.  If you want a 
    snapshot of the whole thing, send e-mail.  But, please, only if you are 
    willing to read it and comment.:
    
    <?xml version="1.0" encoding="UTF-8" standalone=yes ?>
    <!DOCTYPE Ada_Component_Registry [
    <!-- Version 0.2 Doctype Copyright 2003 by Robert I. Eachus, copying 
    allowed, all other rights reserved for now. -->
       <!ELEMENT Registry (Author*, Project+, Entry+) >
       <!ATTLIST Registry
           Name         CDATA  #REQUIRED
           Version      CDATA  #REQUIRED
           Website      CDATA  #IMPLIED
           Copyright    CDATA  #REQUIRED
       >
       <!ELEMENT Project (Author*, Requires*, Supports*, Description?)
       <!ATTLIST Project
           Name         CDATA  #REQUIRED
           Version      CDATA  #IMPLIED
           Website      CDATA  #IMPLIED
           Bug_Reports  CDATA  #REQUIRED
           Copyright    CDATA  #REQUIRED
       >
       <!ELEMENT Entry (Author+, Description?, Requires*, Supports*, 
    Contents?)
       <!ATTLIST Entry
           Name      CDATA  #REQUIRED
           Project   CDATA  #REQUIRED
           Version   CDATA  #IMPLIED
           Source    CDATA  #IMPLIED
           Copyright CDATA  #IMPLIED
       >
       <!ELEMENT Author>
       <!ATTLIST Author
           Name      CDATA  #REQUIRED
           Email     CDATA  #IMPLIED
           Telephone CDATA  #IMPLIED
           Company   CDATA  #IMPLIED
           Address   CDATA  #IMPLIED
       >
       <!ELEMENT Compiler >
       <!ATTLIST Compiler
                 Name    CDATA   #REQUIRED
                 Version CDATA   #IMPLIED
       >
       <!ELEMENT Contents (#PCDATA )>
       <!ELEMENT Database>
       <!ATTLIST Database
                 Name    CDATA   #REQUIRED
                 Version CDATA   #IMPLIED
       >
       <!ELEMENT Date (((Month, Day?)?, Year)|#PCDATA)>
       <!ELEMENT Description (#PCDATA )>
       <!ELEMENT Full_Name (#PCDATA )>
       <!ELEMENT Language
       <!ATTLIST Language
                 Version (Ada80 | Ada83 | Ada95 | Ada2000 | Ada0X) "Ada95"
       <!ELEMENT OS>
       <!ATTLIST OS
                 Name    CDATA   #REQUIRED
                 Version CDATA   #IMPLIED
       >
       <!ELEMENT Project_Name (#PCDATA ) >
       <!ELEMENT Requires (Project_Name|Compiler|OS|Hardware)+ >
       <!ELEMENT Supports (Language_Version|Compiler|OS|Hardware)+ >
       <!ELEMENT Root_Name (#PCDATA )>
       <!ELEMENT URL (#PCDATA ) >
       <!ELEMENT Version (#PCDATA)>
       <!ATTLIST Version Date CDATA >
       <!ELEMENT Website (#PCDATA) >
    ]>
    
       <Registry Name="Ada Component Registry"
                 Version="0.2"
                 Copyright="Copyright 2003 by Robert I. Eachus, copying 
    allowed, all other rights reserved for now."
       >
    
    -- 
                                                 Robert I. Eachus
    
    "Quality is the Buddha. Quality is scientific reality. Quality is the 
    goal of Art. It remains to work these concepts into a practical, 
    down-to-earth context, and for this there is nothing more practical or 
    down-to-earth than what I have been talking about all along...the repair

    of an old motorcycle."  -- from Zen and the Art of Motorcycle 
    Maintenance by Robert Pirsig
    
    
    
    

Re: Ada Component Registry proposal

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> No intent to exclude anyone, but XML is still not all that common a 
> language, and I felt the intersection of those who knew XML well enough 
> to comment, and were also interested in the registry project would be 
> pretty small.

Yes, this is most probably true - both things are doubtful: XML does not seem
good notation, it is probably worse that many programming languages in this
respect... perhaps there should be translators *into* XML; as for the registry
project, it is still unclear why it will be more useful than, say, AdaPower,
and whether it has chances to survive.

>  Hmmm.  Actually, why not?  Here is the current XML 
> DOCTYPE, and the start of the registry declaration.

>From what is presented so far, I conclude that the registry will contain only
one major kind of entities - Projects. I think that this is wrong way to go,
because such a registry will not differ fundamentally from corresponding part
of AdaPower (still most successful Ada-oriented website), and will suffer from
the same principal problems (yes, it may be equipped with various technical,
legal and procedural elements, but all that will not save the thing).

I think that any really useful and alive registry of this kind should contain
also 2 other major kinds of entities: 1) reviews and 2) design patterns.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ada Component Registry proposal

[sk]

"Robert I. Eachus" <rieachus@comcast.net>:
 > Here is the current XML DOCTYPE, and the ...

Is your proposal just for a registry of packages and not
to actually put together a library in terms of packages ?

I must admit that if this is the case, I have probably
volunteered for something I thought was something else :-)

Another thought, what would the "registry" provide more than
an equivalent web page of links to other peoples packages ?

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[sk]

"Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru>
 > ... not differ fundamentally from corresponding part
 > of AdaPower (still most successful Ada-oriented website) ...

Perhaps AdaIC would be a better comparison

http://adaic.com/site/index.html

lot of dead/bad links though.

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Robert I. Eachus]

sk wrote:

> Is your proposal just for a registry of packages and not
> to actually put together a library in terms of packages ?

Correct.  It should end up being an inventory of what exists and is 
available, as well as, a guide to who is using which names.  But that is 
information useful to someone putting together a consistant library, not 
a library in and of itself.

> I must admit that if this is the case, I have probably
> volunteered for something I thought was something else :-)
> 
> Another thought, what would the "registry" provide more than
> an equivalent web page of links to other peoples packages ?

Yes.  If nothing else the existance of the registry should make it much 
easier for people to find out what is "out there" and available for use. 
  So it will promote reuse just by existing.

But only if combined with a project to pull together a joint library 
will it fullfill its intended purpose.  I chose this as a first step I 
can make happen.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F9879DA.6070205@comcast.net...
>
> Yes.  If nothing else the existance of the registry should make it much
> easier for people to find out what is "out there" and available for use.
>   So it will promote reuse just by existing.
>
> But only if combined with a project to pull together a joint library
> will it fullfill its intended purpose.  I chose this as a first step I
> can make happen.
>
> -- 
>                                                      Robert I. Eachus

I see that as a good first step.  For all of us whether we just want to know
what's out there or want to create our own in fields not yet touched by what
is out there, we need to know somehow.  Once we have that list of existing
stuff out there, we can fill in the gaps.  Talk to the authors of what's out
there see what we can do about incorporating their efforts within the
library, etc etc..

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Ada Component Registry proposal

[Alexandre E. Kopilovitch]

sk wrote:

> > ... not differ fundamentally from corresponding part
> > of AdaPower (still most successful Ada-oriented website) ...
>
> Perhaps AdaIC would be a better comparison

I doubt it. AdaIC has somehow another purpose, I think... although there is
certainly substantial intersection.

> >http://adaic.com/site/index.html
>
> lot of dead/bad links though.

Not only dead/bad, but also improper ones. I just glanced there... better I
did not do that. In the list of national Ada organizations I discovered
Ada-Russia, to my surprise; I followed the link, and found simply website in
Russian. Yes, it is dedicated for Ada, and contains Ada-related materials and
links, but I found there no traces of any organization. Then I checked list
of associated organizations in Ada-Europe, and as I expected there are no
Ada Russia. So, this name is premature, at best. But this was not the worse:
on that site (pseudo- Ada Russia) I discovered new Ada textbook in Russian,
(not a translation, but presented as original writing) and glanced into it
too... again, better I did not do it. Well, as I feared (by past experience)
all symptoms are in place, beginning from the book title, which demonstrates
playing with words - this title may be read as slang form of "Ada programming"
or normal language form of "Hell programming". Then follows the substance of
the book with all usual terminological negligence; the highest achievement is,
perhaps, translation of the term "elaboration"... but I may be mistaken here -
I looked into the text about 5 minutes only, so there may be even greater
invention. Well, I understand - good intentions, as usual.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ada Component Registry proposal

[Georg Bauhaus]

Robert C. Leif <rleif@rleif.com> wrote:
:    
:    Why are you using a DTD, which is the antithesis of Ada? A schema which
: is the semantic equivalent (translation) of a collection of Ada types would
: be far more appropriate. 

I think before considering whether the C/Unix oriented Schema type
library is a restriction or an improvement, it is, first of all,
necessary to consider which Elements should be in the registry,
then their relations, and then whether an XML-DTD schema, or a
RELAX NG schema, or a Schema schema is more useful.


Georg

Re: Ada Component Registry proposal

[sk]

"Robert I. Eachus" <rieachus@comcast.net>:
 > Correct. ...

Fair enough. Makes any of my proposed naming schemes
irrelevent though :-)

So it would seem that your DB categories would be
something along the lines of "Vendors", "Tools", "Papers",
"Libraries" etc ? Or would you be limiting to code
based ("Libraries", "Tools") items ?

 > ... "out there" and available for use

I like the idea of being able to centrally find what is
"out there". Traveling from AdaIC yesterday reminded me of
links and introduced me to others. However, there are
too many dead/bad/out-of-date links (not just AdaIC,
AdaPower too) which quickly discourages one from further
exploration and hints (possibly falsly) at a lack of website
interest or maintenence.

I know I should wait for your HTML publication before asking,
but have you allowed for a mechanism, within the Registry,
which will ensure that a potential user does not quickly
get annoyed by dead-[links,entries] and give up using it ?

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

"sk" <noname@myob.com> wrote in message >
> I know I should wait for your HTML publication before asking,
> but have you allowed for a mechanism, within the Registry,
> which will ensure that a potential user does not quickly
> get annoyed by dead-[links,entries] and give up using it ?
>
> -- 
> -------------------------------------------------
> -- Merge vertically for real address
> --
> --     s n p @ t . o
> --      k i e k c c m
> -------------------------------------------------
>
I think I can answer that one well to a certain point :-).

You see, ultimately we could do a bot of our own crawling the web as per the
list of URLs tha appear in the XML file and write a log (successful or non
successful) in trying to get to the library's webpage. The library authors
would need to assure to update such things as URL Changes to their libraries
or to noticy somehow (via email perhaps) or simply by udpating the XML file
that the library is out of commission or could be taken over by someone
else.

Likewise we could also, instead of linking to, hosting the libraries
themselves so that it doesn't become the responsibility of the author but of
the library maintenance team to assure proper linkage to available source
code.  Of course this last suggestion is pending the author's approval to
have his library hosted (or mirror) on the library website.(in lieu of or in
addition to the current place where the library is hosted).  Just for the
sake that should the author's current location go down or the library is
abandonned (for any reason) then perhaps another programmer can continue
it's development right on the website).  Of course, as mentionned, this
would work provided the library authors agree to having us host the code (or
mirror ir) locally here.

Having each library element hosted locally would give us full control over
the availability of the library which does have it's advantage :-).  not to
mention an instant backup for the authors in case their other hosting places
go down whether for maintenance or permanently we'd still have their
library(ies) there for them.

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Ada Component Registry proposal

[sk]

"Robert I. Eachus" <rieachus@comcast.net>
 > Don't worry about it. ...

That it is the lead in to so many jokes ("Trust me...",)
that they aren't funny anymore:-)

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[sk]

Stephane Richard <stephane.richard@verizon.net>:
 > ... bot of our own crawling the web ...

A manual crawl from AdaIC's site map from "Cetus OO-Ada",
for example, quickly leads to a seeming infinite links
to links etc.

Based on the above, and
 > ... provided the library authors agree to having us host
 > the code ...
[at AdaWorld, presumably] this is *massive*.

Gaining the cooperation of all concerned might be a problem
especially over the hosting issue.

How big a problem I do not know, but it could render the
Registry useless if valuable resources do not wish to
participate. Or even worse, participate with everything but
the hosting and then disappear.

 > ... library maintenance team ...

Is it a library or a Registry ?

This is an important distinction for me which can probably
only be answered by waiting for RIEachus' full proposal :-)

--
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Robert I. Eachus]

sk wrote:

> This is an important distinction for me which can probably
> only be answered by waiting for RIEachus' full proposal :-)

The problem is one of terminology.  I am developing A registry, and a 
set registry maintenance software and tools that should result in many 
people taking THE registry, and adding their proprietary software 
libraries to it.  No reason they shouldn't, and if they do it by having 
a local registry they merge with each new release of THE registry, the 
whole process should be fairly painless.  If at some point they decide 
to publish some of their local tools, great.

In the context of what I will call the Common Ada Library (CAL) 
proposal, the registry software can be used to maintain a subset which 
is the CAL.  It would almost certainly have much stricter rules for 
inclusion than my version of the registry.  Again, if people want to 
comply with the "extra" rules needed for CAL and sumbit their software 
there, great.  So the goal is that software  components will migrate:

   Local library/registry --> Global registry --> CAL.

That is part of what I mean when I talk about evolution.

-- 
                                             Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[Robert I. Eachus]

sk wrote:

 > That it is the lead in to so many jokes ("Trust me...",) that they
 > aren't funny anymore:-)

But in this case, it is true.  The only reason I didn't post the current
state of the registry here was that I felt it would be unnecessary
clutter.  I will probably have it up on my web site sometime in the next
few weeks, and probably on some other Ada websites as well.  Keeping the
whole process open is necessary if it is to succeed, and I expect that 
for most software, the authors will be the ones to create and maintain 
the registry entries.  The only potential problem is that if the 
software for adding material to a site is posted and used "too soon,"
authors may give up if there are too many changes and the software 
changes too often.  That is what I am trying to avoid.

-- 
                                           Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the
goal of Art. It remains to work these concepts into a practical,
down-to-earth context, and for this there is nothing more practical or
down-to-earth than what I have been talking about all along...the repair
of an old motorcycle."  -- from Zen and the Art of Motorcycle
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[tmoran]

>You see, ultimately we could do a bot of our own crawling the web as per the
>list of URLs tha appear in the XML file and write a log (successful or non
>successful) in trying to get to the library's webpage. The library authors
  www.adapower.com/os/finder.html
has an early version of a crawler for finding dead links.  The current
version also handles robots.txt, cookies, and more.  It's available.

Re: Ada Component Registry proposal

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> > Is your proposal just for a registry of packages and not
> > to actually put together a library in terms of packages ?
>
> Correct.  It should end up being an inventory of what exists and is 
> available, as well as, a guide to who is using which names.  But that is 
> information useful to someone putting together a consistant library, not 
> a library in and of itself.
>
> > I must admit that if this is the case, I have probably
> > volunteered for something I thought was something else :-)
> > 
> > Another thought, what would the "registry" provide more than
> > an equivalent web page of links to other peoples packages ?
>
> Yes.  If nothing else the existance of the registry should make it much 
> easier for people to find out what is "out there" and available for use. 
>  So it will promote reuse just by existing.
>
> But only if combined with a project to pull together a joint library 
> will it fullfill its intended purpose.  I chose this as a first step I 
> can make happen.

As far as I can see now, there are 2 very different purposes for the Registry.
They have in common a major notion of "referencing", but in other respects
they are different and even possibly potentially conflicting.

First of them is pure Software Engineering purpose: to have a firmly established
way for unambiguous referencing a known component. This is something similar
to Java "packages" in its purpose (but not in design), yes?

The second purpose is providing a kind of searchable public database where one
can find candidates for reuse. This database should differ from other public
resources of this kind in that that it should be better suited for systematic
and organized software development.

Then, if I understand correctly, the first purpose is considered as primary
one; and at this initial stage it takes all attention, while the second purpose
is expected to care for itself for some time. Well, this seems quite reasonable.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ada Component Registry proposal

[sk]

"Robert I. Eachus" <rieachus@comcast.net>
 > ... should result in many people taking THE registry ...

Randy Brukardt recently noted that AdaIC has ability to
find libraries ("Re: setjmp/longjmp?" thread) and then

"The only problem with it is that a lot of people never
have nominated their sites for inclusion. (In which case,
of course, they're not indexed at all.)"

My question is why would you expect the participation
with the Registry to be any different than the experience
with AdaIC or other websites ?

 > ... set registry maintenance software and tools ...
I am not going to waste any more of your time on implementation
details until you have published your proposal so that there
is actually something to comment about.

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Robert I. Eachus]

sk wrote:

> My question is why would you expect the participation
> with the Registry to be any different than the experience
> with AdaIC or other websites ?

Different purpose if you will.  Registering a website or whatever on 
AdaIC just adds one more place that people can look and maybe find your 
reusable library.  With the registry, the main benefit for everyone is a 
standard format for describing reusable software.  Even if you don't 
share your software with anyone, or outside your own company, using the 
standard repository format to describe and link to it should make it 
easier for people to use--even you.  (And if it doesn't do that, it will 
  fail.)

And what I have already found from experiments is that the level of 
effort to do a good job of entering an existing library is significant, 
but the rewards are worth it.  For example, did you know that there is a 
binding to Oracle's OCI as part of GNADE?  I didn't until I downloaded 
the Zip file and walked the directory heirarchy looking to see what was 
there.

-- 
                                        Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[Robert I. Eachus]

Alexandre E. Kopilovitch wrote:

> As far as I can see now, there are 2 very different purposes for the Registry.
> They have in common a major notion of "referencing", but in other respects
> they are different and even possibly potentially conflicting.
> 
> First of them is pure Software Engineering purpose: to have a firmly established
> way for unambiguous referencing a known component. This is something similar
> to Java "packages" in its purpose (but not in design), yes?
> 
> The second purpose is providing a kind of searchable public database where one
> can find candidates for reuse. This database should differ from other public
> resources of this kind in that that it should be better suited for systematic
> and organized software development.

Correct, but both these purposes/uses are equally important.

> Then, if I understand correctly, the first purpose is considered as primary
> one; and at this initial stage it takes all attention, while the second purpose
> is expected to care for itself for some time. Well, this seems quite reasonable.

Actually, I think I will end up devoting more of my time this week to 
the second purpose.  This is in part because it needs to be more of a 
centralized activity.  Once the maintenance tools are available, anyone 
will be able to submit entries, updates, or corrections.


-- 
                                         Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[Marius Amado Alves]

On Sat, 2003-10-25 at 17:43, Robert I. Eachus wrote:
> sk wrote:
> 
> > My question is why would you expect the participation
> > with the Registry to be any different than the experience
> > with AdaIC or other websites ?
> 
> Different purpose if you will.  Registering a website or whatever on 
> AdaIC just adds one more place that people can look and maybe find your 
> reusable library.  With the registry, the main benefit for everyone is a 
> standard format for describing reusable software.

That sounds no less than solving the essential difficulty of
component-oriented software engineering--GO FOR IT!

But I agree with others on this list that a volunteer basis only will
not get us there. Some hard commitment i.e. money is necessary. And some
kind of executive/business plan is necessary to gather this kind of
support. Note I'm not against the current technical work on the
Registry. This and other technical elements are necessary for *any*
plan. I also feel the lack of a work plan.

A marketeer's challenge: a shorter term for "solving the essential
difficulty of component-oriented software engineering." Tip:
"component-oriented programming" = "mega-programming".

Re: Ada Component Registry proposal

[Marin David Condic]

I don't think that a committment of money is necessary at exactly this 
point in time - although if the vendors or the government or someone 
wants to jump up and fund the whole thing, I wouldn't stop them. ;-)

What would be a good first step from the standpoint of the vendors would 
be simply to indicate some interest in the project and a willingness to 
participate in some way to guide it along, with the implication that a 
successful start would be adopted and distributed with their compilers. 
(No committments - just a willingness to distribute it *if* it meets 
expectations.)

Money is a matter that needs to be considered if they expect the library 
to get any bigger than a few container packages. If all they want is 
container packages, there's plenty of "Volunteer-Speculation-Efforts" 
out there from which to pick already.

MDC

Marius Amado Alves wrote:
> 
> But I agree with others on this list that a volunteer basis only will
> not get us there. Some hard commitment i.e. money is necessary. And some
> kind of executive/business plan is necessary to gather this kind of
> support. Note I'm not against the current technical work on the
> Registry. This and other technical elements are necessary for *any*
> plan. I also feel the lack of a work plan.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================

Re: Ada Component Registry proposal

[Robert I. Eachus]

Marin David Condic wrote:
> I don't think that a committment of money is necessary at exactly this 
> point in time - although if the vendors or the government or someone 
> wants to jump up and fund the whole thing, I wouldn't stop them. ;-)

Same here.  Someone jumping up and supporting the registry part might 
seem like a wonderful thought, but I think I need to push things along 
further before adding money to the equation would help, not hurt.

Another way of saying it is that as long as everything is on a volunteer 
basis, there is no time spent arguing about/deciding how or where the 
money should be spent.

-- 
                                          Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[Marin David Condic]

Yeah, but it would be nice to see that all/some/one of the vendors had 
some mild interest in the project - or is it all a pipe dream?

MDC

Robert I. Eachus wrote:
> 
> Another way of saying it is that as long as everything is on a volunteer 
> basis, there is no time spent arguing about/deciding how or where the 
> money should be spent.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================

Re: Ada Component Registry proposal

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

Well I talked to ACT quickly, I'm still waiting for a phone call which it
looks like I'll have to remind them of it seems :-).  But nonetheless, they
did recognize the effort, they do follow c.l.a. pretty good, now to wait for
em to say something.  but I need to talk to that dude first.  Guess at the
time it was too early to pronounce themselves but they didn't categorically
reject it either (so far).  Maybe all they are waiting for is something to
look at (hence what Robert is doing) so they can see how it is planned to
work, give them a basis of an idea of what it might look like and as Robert
said how easily usable it is as far as concepts goes.

I'll get in touch with them again monday probably.

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F9AEB09.9020102@noplace.com...
> Yeah, but it would be nice to see that all/some/one of the vendors had
> some mild interest in the project - or is it all a pipe dream?
>
> MDC
>
> Robert I. Eachus wrote:
> >
> > Another way of saying it is that as long as everything is on a volunteer
> > basis, there is no time spent arguing about/deciding how or where the
> > money should be spent.
> >
>
>
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/NSFrames.htm
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>      "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
>      basically a Microsoft operating system - it runs for a while and
>      then crashes and reboots. By design, no less. Neo is just a
>      memory leak that's too hard to fix, so they left him in... The
>      users don't complain because they're packed in slush and kept
>      sedated"
>
>          --  Marin D. Condic
> ======================================================================
>

Re: Ada Component Registry proposal

[sk]

"Robert I. Eachus" <rieachus@comcast.net>:
 > Different purpose if you will. ...
Still not convinced that *participation* will be significantly
different from "link-farms" (meant in positive sense), but
for the moment I will yield that issue.

me:
 > I am not going to waste any more of your time on
 > implementation details
Sorry, breaking my intentions. In case you havn't included a
"field" for dependencies, you probably need to. For example,
the OpenGL binding depends on AdaBindX.

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Marin David Condic]

Well, that's something. ACT is probably the most active in enhancing 
their Ada product - I don't know what the other vendors are up to or if 
they anticipate making any significant enhancements to their compiler at 
all. If ACT were driving it and it was available for other vendors to 
adopt, that might be a suitable way to go.

It might be a good idea to get a read on the relative interest of other 
vendors and some fix on how actively they are developing their compiler. 
That's where the ARG could be useful - if a vendor has a representative 
on the ARG, they are probably interested in Ada's future, have some 
willingness to extend their Ada product and could be asked to comment on 
  the interest in a library. If they don't have a representative on the 
ARG, then its a good bet they aren't terribly interested in any future 
enhancements to their Ada compiler - if they don't care enough about 
major syntactic/semantic changes to Ada, then they almost certainly 
won't care about a relatively lesser thing like a library.

One other thing the ARG would be good for - comment on what is already 
planned or likely to be planned for the next issue of Ada. I had heard 
talk of a file system interface package and probably some additional 
things, but I don't know that there is a current plan to have any sort 
of containers. They might conceivably comment on two other issues: 1) If 
Ada were to get a CAL, what should the first area(s) of priority be? 
(Containers? Math? Network? OS?...) 2) Are there any criteria they would 
find important in ultimately accepting or rejecting a CAL as being "part 
of Ada"? (Style issues? Domain issues? Platform issues? - Basically what 
sorts of things might get the CAL shot down and rejected.)

Since we have an ARG member (or two, or three...) listening in - maybe 
there's some comment? Say something to me off line if you'd prefer to 
discuss it out of the public eye. (See my return address in the .SIG)

MDC

Stephane Richard wrote:
> Well I talked to ACT quickly, I'm still waiting for a phone call which it
> looks like I'll have to remind them of it seems :-).  But nonetheless, they
> did recognize the effort, they do follow c.l.a. pretty good, now to wait for
> em to say something.  but I need to talk to that dude first.  Guess at the
> time it was too early to pronounce themselves but they didn't categorically
> reject it either (so far).  Maybe all they are waiting for is something to
> look at (hence what Robert is doing) so they can see how it is planned to
> work, give them a basis of an idea of what it might look like and as Robert
> said how easily usable it is as far as concepts goes.
> 
> I'll get in touch with them again monday probably.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================

Re: Ada Component Registry proposal

[Martin Dowie]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F9BCDE0.1070704@noplace.com...
> One other thing the ARG would be good for - comment on what is already
> planned or likely to be planned for the next issue of Ada. I had heard
> talk of a file system interface package and probably some additional
> things, but I don't know that there is a current plan to have any sort
> of containers.

No, check out AI-302 (both proposals :-)

Re: Ada Component Registry proposal

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3963 bytes --]

Yeah, it's a step in the right direction :-).   I just emailed him again to
arrange another phone call if he can.  I also stated questions and issues
(as in what we'd like from vendors in general).  so he can answer them if he
can't call me...so we'll see tomorrow or tuesday :-).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F9BCDE0.1070704@noplace.com...
> Well, that's something. ACT is probably the most active in enhancing
> their Ada product - I don't know what the other vendors are up to or if
> they anticipate making any significant enhancements to their compiler at
> all. If ACT were driving it and it was available for other vendors to
> adopt, that might be a suitable way to go.
>
> It might be a good idea to get a read on the relative interest of other
> vendors and some fix on how actively they are developing their compiler.
> That's where the ARG could be useful - if a vendor has a representative
> on the ARG, they are probably interested in Ada's future, have some
> willingness to extend their Ada product and could be asked to comment on
>   the interest in a library. If they don't have a representative on the
> ARG, then its a good bet they aren't terribly interested in any future
> enhancements to their Ada compiler - if they don't care enough about
> major syntactic/semantic changes to Ada, then they almost certainly
> won't care about a relatively lesser thing like a library.
>
> One other thing the ARG would be good for - comment on what is already
> planned or likely to be planned for the next issue of Ada. I had heard
> talk of a file system interface package and probably some additional
> things, but I don't know that there is a current plan to have any sort
> of containers. They might conceivably comment on two other issues: 1) If
> Ada were to get a CAL, what should the first area(s) of priority be?
> (Containers? Math? Network? OS?...) 2) Are there any criteria they would
> find important in ultimately accepting or rejecting a CAL as being "part
> of Ada"? (Style issues? Domain issues? Platform issues? - Basically what
> sorts of things might get the CAL shot down and rejected.)
>
> Since we have an ARG member (or two, or three...) listening in - maybe
> there's some comment? Say something to me off line if you'd prefer to
> discuss it out of the public eye. (See my return address in the .SIG)
>
> MDC
>
> Stephane Richard wrote:
> > Well I talked to ACT quickly, I'm still waiting for a phone call which
it
> > looks like I'll have to remind them of it seems :-).  But nonetheless,
they
> > did recognize the effort, they do follow c.l.a. pretty good, now to wait
for
> > em to say something.  but I need to talk to that dude first.  Guess at
the
> > time it was too early to pronounce themselves but they didn't
categorically
> > reject it either (so far).  Maybe all they are waiting for is something
to
> > look at (hence what Robert is doing) so they can see how it is planned
to
> > work, give them a basis of an idea of what it might look like and as
Robert
> > said how easily usable it is as far as concepts goes.
> >
> > I'll get in touch with them again monday probably.
> >
>
>
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/NSFrames.htm
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>      "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
>      basically a Microsoft operating system - it runs for a while and
>      then crashes and reboots. By design, no less. Neo is just a
>      memory leak that's too hard to fix, so they left him in... The
>      users don't complain because they're packed in slush and kept
>      sedated"
>
>          --  Marin D. Condic
> ======================================================================
>

Re: Ada Component Registry proposal

[sk]

Martin Dowie <martin.dowie@btopenworld.com>:
 > No, check out AI-302 (both proposals :-)

After *scanning* these AI's can I ask if there
is any thought to keeping additional libraries
*out* of the ARM and in a separate hierarchy.

I ask, because the thrust of the naming schemes
I proposed earlier in the thread were to try to
keep away from the "Ada.*", "Interfaces.*" etc
unless necessary. The additional libraries are
just something that I think is not part of the
core language definition.

If there are any thoughts in this direction, how
seriously are they being considered ?


-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Ada Component Registry proposal

[Robert I. Eachus]

sk wrote:

> Sorry, breaking my intentions. In case you havn't included a
> "field" for dependencies, you probably need to. For example,
> the OpenGL binding depends on AdaBindX.

Right now I have a Requires entry that can include other projects, 
compilers, Ada versions, hardware or operating systems.  It will 
probably get expanded a bit to allow for bindings to non-Ada code to say 
what they bind to.  (Or that may end up as a different type of entry. 
"Binds to" perhaps?)

There is also a category Supports which is similar but different in 
intent.  If software has been ported to several compilers or several 
operating systems, this allows documentation of what versions are known 
to be supported.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Ada Component Registry proposal

[chris]

sk wrote:

> Sorry, breaking my intentions. In case you havn't included a
> "field" for dependencies, you probably need to. For example,
> the OpenGL binding depends on AdaBindX.

Don't think it does anymore... not sure though.

Re: Ada Component Registry proposal

[Marin David Condic]

"No" - what? Not clear. "No, there isn't a file system interface"? "No, 
there isn't a container library"? There was talk of having some ability 
to access directories and files via some standard Ada package, so I know 
that was discussed. Not planned?

If the ARG is not planning to add a container library, would they like 
to see one as the first priority? Any problem with the ones that already 
exist? (Id est, let's not go build yet another container library and do 
the same things that made existing ones unattractive...)

MDC


Martin Dowie wrote:
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:3F9BCDE0.1070704@noplace.com...
> 
>>One other thing the ARG would be good for - comment on what is already
>>planned or likely to be planned for the next issue of Ada. I had heard
>>talk of a file system interface package and probably some additional
>>things, but I don't know that there is a current plan to have any sort
>>of containers.
> 
> 
> No, check out AI-302 (both proposals :-)
> 
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================