* Ada.Networks.Sockets hierarchy for standardization? @ 2003-05-31 5:01 Warren W. Gay VE3WWG 2003-05-31 6:33 ` Tarjei T. Jensen 2003-05-31 17:24 ` Michael Erdmann 0 siblings, 2 replies; 27+ messages in thread From: Warren W. Gay VE3WWG @ 2003-05-31 5:01 UTC (permalink / raw) For discussion: I have thrown together this evening a more formalized view of some "chicken scratching" I did on my train commute home this evening. The diagram is available at my web site (see PDF link further on). While we're on the subject of sockets and URLs, here is a shameless plug 8-) for my "Linux Socket Programming by Example" book (sorry folks, its C/C++ based): http://www.amazon.com/exec/obidos/ASIN/0789722410/qid%3D996033092/104-8302379-1659946 Before jumping right to the diagram, please read the following first (otherwise you might GOL (Gasp Out Loud)). IIRC, earlier discussions centered around something rather simple like Ada.Sockets as providing all/mostly all of the basic needs of application programmers. I am going to propose something a little bit different, but I do believe that this requirement for simplicity should be accomodated. But I believe starting off too simple would be a great mistake, and severely limit what could otherwise be a successful, and nearly complete longer term model for Ada. To address the "simple requirements" class of applications, I have included in the diagram the package Ada.Networks.Simple, for lack of a better name at the moment. Maybe "Basic" would be better. This package can then use renames and other basic Ada techniques to pull together all of the basic facilities into one place, that would otherwise have to be pulled from a number of other packages and child packages (a la cart). Now it is probably safe to view the diagram: http://home.cogeco.ca/~ve3wwg/Ada.Networks_Hierarchy.PDF Now you're probably wondering why we need all these "flippin packages"? Here's my reasons below: You will need to lump many aspects of networking under one umbrella. There is much more to sockets than just sockets however. I mentioned the need for name services in an earlier thread. For this reason, and others, I think we will need to have a top level Ada.Networks package to bring the common elements together. In my book, I spend an entire chapter showing how to form socket addresses. This is important because it is a somewhat arcane thing in C, and the many forms of addresses makes this essential to cover. I also believe that Ada will need a top level Ada.Networks.Addresses package from which to derive child packages for IPv4, IPv6, X.25, AX.25, AppleTalk and other addresses (also to derive from abstract tagged records etc.) To allow for extension and additions, I propose that we then add child packages in the form Ada.Networks.Addresses.IPv4, IPv6 etc. Internet addresses are usually known by names these days, rather than their IP#'s as in the years gone by. Hence the need for the Ada.Networks.Name_Services top level package. Then its subdivided by protocol (I show Internet and X.500). BTW, I am not suggesting that all of these need to be part of any initial "offering". But I do believe we need to make room for them ;-) Of course, there is the all important Ada.Networks.Sockets top level package. I can envision 3 child packages, where the most important one is the Berkeley sockets, and the XTI sockets. Some may want to also add in WinSock, though now that XP supports Berkeley sockets, there may not be any real need for this anymore. I don't want it, but I left a spot for it. These packages would concern themselves strictly with the creating, binding, listening, accepting and other socket basic functions. The Socket_Type would act as a "handle". I don't see I/O functions being included here, but this is obviously open to discussion. Of course, security is important, and I am not so sure that I have properly planned for that here. I have suggested that we need a Ada.Networks.Filters which includes a child package SSL, that can be "pushed" onto an open socket similar to the way AT&T UNIX streams worked. The Ada.Networks.Protocols and their child packages (particularly Internet) provided constants that pertain to the types of sockets required. These packages would have constants that select TCP, IP, UDP, ICMP etc. when creating a socket. Other protocols of course are possible, and Linux I know supports X.25 and the amateur radio AX.25 as two other examples. The package Ada.Networks.Services.Internet is what you would use to map http to port 80, ftp to port 21, etc. These are covered by the services database UNIX calls, and map well known services to port numbers. I have thrown in Ada.Networks.XDR to provide endian neutral communications a la RPC in the C world. Perhaps this can be used again in "push" fashion on a socket. The placement and organization of this in large part depends upon a successful implementation. TBD. Ada.Networks.Streams, as I see it, would take a Socket_Type and return some Stream_Type that you could perform various I/O types of operations on. It would also include a function to re-expose Socket_Type, so that calls like shutdown(2) can be performed, if you were only given a Stream_Type in a subprogram, for example. From Ada.Networks.Streams, I think you could branch out into varous things like XML, SOAP, ftp, http etc, and perhaps Text_IO belongs here (I am not sure about this yet though). But I think this can work. Finally, package Ada.Networks.Simple would then pull together in one place, the basic elements out of all of the packages in Red, that are necessary for the most basic TCP/IP application needs. This is like using Simon Wright's fine Booch Components, which is a bit tricky to instantiate. I use my own "wrapper generics" to do the same thing that Ada.Networks.Simple should be able to do, ie, to make it possible to instantiate everyting in one "go". The Ada.Networks.Simple would be a "wrapper package" for simplicity's sake. I see the packages in red as being essential to anything that is close to being complete. The rest would be gravy, but these are things that I think we should shoot for. Keep in mind that the C world already has access to all of these things, without any further effort. Because of this, I think we should support what is possible. Most of this stuff is just writing careful thick binding support. Doing the XDR part portability, is tricky, but the payback is there. What do you think? -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Ada.Networks.Sockets hierarchy for standardization? 2003-05-31 5:01 Ada.Networks.Sockets hierarchy for standardization? Warren W. Gay VE3WWG @ 2003-05-31 6:33 ` Tarjei T. Jensen 2003-05-31 13:35 ` Simon Wright 2003-05-31 17:24 ` Michael Erdmann 1 sibling, 1 reply; 27+ messages in thread From: Tarjei T. Jensen @ 2003-05-31 6:33 UTC (permalink / raw) "Warren W. Gay wrote: > For discussion: I have thrown together this evening > a more formalized view of some "chicken scratching" I did on my > train commute home this evening. The diagram is available at my > web site (see PDF link further on). First impressions is "not so bad". However I would re-arrange. I would make sockets the top level node and arrange everything around that (forget about the ada node; this is Ada. I would change some names. e.g. streams should be protocols, protocols should be transport (or something like that). Anyway, I'm worried that the network programming might drown in a ocean of packages. greetings, ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Ada.Networks.Sockets hierarchy for standardization? 2003-05-31 6:33 ` Tarjei T. Jensen @ 2003-05-31 13:35 ` Simon Wright 0 siblings, 0 replies; 27+ messages in thread From: Simon Wright @ 2003-05-31 13:35 UTC (permalink / raw) "Tarjei T. Jensen" <tarjei@online.no> writes: > However I would re-arrange. I would make sockets the top level node > and arrange everything around that (forget about the ada node; this > is Ada. If it's to be related to the standard it should start at Ada (like Ada.Streams etc). Someone else as adopted "Ada0Y" as the top level to avoid compiler complaints about recompiling standard units. > Anyway, I'm worried that the network programming might drown in a > ocean of packages. Better that than munging everything together so the concepts are entangled. I dare say there's ahappy medium. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Ada.Networks.Sockets hierarchy for standardization? 2003-05-31 5:01 Ada.Networks.Sockets hierarchy for standardization? Warren W. Gay VE3WWG 2003-05-31 6:33 ` Tarjei T. Jensen @ 2003-05-31 17:24 ` Michael Erdmann 2003-05-31 1:35 ` Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std) Warren W. Gay VE3WWG 2003-05-31 23:47 ` Ada.Networks.Sockets hierarchy for standardization? Warren W. Gay VE3WWG 1 sibling, 2 replies; 27+ messages in thread From: Michael Erdmann @ 2003-05-31 17:24 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > For discussion: I have thrown together this evening > a more formalized view of some "chicken scratching" I did on my > train commute home this evening. The diagram is available at my > web site (see PDF link further on). I like it. But may be the names services should be put under Services. Maybe i have missed it, but what is the difference between red and black boxes? Michael ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std) 2003-05-31 17:24 ` Michael Erdmann @ 2003-05-31 1:35 ` Warren W. Gay VE3WWG 2003-06-01 4:02 ` Randy Brukardt 2003-05-31 23:47 ` Ada.Networks.Sockets hierarchy for standardization? Warren W. Gay VE3WWG 1 sibling, 1 reply; 27+ messages in thread From: Warren W. Gay VE3WWG @ 2003-05-31 1:35 UTC (permalink / raw) Michael Erdmann wrote: > Warren W. Gay VE3WWG wrote: >> For discussion: I have thrown together this evening >> a more formalized view of some "chicken scratching" I did on my >> train commute home this evening. The diagram is available at my >> web site (see PDF link further on). > > I like it. But may be the names services should be put under > Services. ... > Michael While it is too soon to judge general interest in this project, based upon the pulse of other Ada socket articles in this newsgroup, I think it is time _something_ was _started_ in this vein. Funding would be nice, but I don't think we can wait for it. The clock is ticking. Rather than lose precious time on this, since defining standards and reference implementations can require considerable effort, I have taken some initiative and registered a request at sourcforge for an ada0Y-net-std project to be created there. The website indicates that they need 2 business days to review and to respond to the request. If all goes well, I hope to have a project started there by next Wednesday (June 4th). There we can hold discussions, and more easily post and revise documents, and later code. They also provide NNTP access, though I don't know how well it works yet. If it works well, this would give us our own private newsgroup in which to hold project discussions in. Alternatively, I suppose an email list is ok, but I prefer a newsgroup approach, if possible. This is not to say that no input will be solicited from comp.lang.ada. Au contrare! However, to reach consensus, you pretty much have to narrow the list of participants, or your discussion will become a free-for-all. Meetings with many people take longer and usually accomplish less. I don't believe that there is much time for us to waste (if Ada0Y means 2005, then there is little time waste). The way I see things happening, is that a summary will be posted here in comp.lang.ada periodically. Interested participants can then come back to the forge's NNTP server and review past discussions and post their comments and contributions. I will be looking for volunteers for various things. I can volunteer my some of my own time on various things and code, but depending upon when the submission deadline is, I'll probably need other people to contribute code and documents as well. Can anyone state when our ARG submission deadline is? Randy? For this project to be successful, this project must have someone to run with this once we have a reference implementation and document (I don't think I'm the best person for that job). At a minimum, we need the document to submit (the reference implementation is to simply help us flush out the problems). So I need someone to work with the ARG: preferably someone more knowledgeable about that standards process and perhaps does Ada as their day job (I am just an Ada hobbiest, after all). By taking this initiative, I am not necessarily presuming that I should be the "moderator" or "organizer" of this effort. I would gladly hand it over to someone else, if they will take the reins and lead this horse to success. I am just assuming that nobody really wants to take the time to do this, and so I'll contribute what I can to this process and at least get things going. If no one steps up to the plate, then I am willing to take this as far as I am able to. I am really hoping however, that I can get at least one volunteer to eventually write up the necessary documentation to submit to the ARG, in the language and preciseness that they need. There are already some socket bindings out there, in different forms. I would be interested in hearing if any of these copyright owners would be willing to allow portions of those packages to be spliced into a new framework, for inclusion into the reference implementation. This project aims to provide a GNAT reference implementation, to help work out problems. I have registered the sourceforge project to use the LGPL license, but I suspect that this also needs to be further discussed and revised (a license selection was required to make the application for a hosted project). If you can contribute existing code, then please indicate what your copyright requirements/restrictions are. In the worst case of failure, we may just end up with another non-standard sockets library (or even worse I guess, it might remain unfinished). But I _want_ this to succeed and I think there is enough interest generally that this _can_ work. It is my personal opinion that an Ada without standard socket library support will cause the language to wither and die, for general purpose computing uses. Networking today is nearly as important as doing Text_IO. Your thoughts? If you are interested in this project, please indicate what you can contribute, and capacity/when/how-much if applicable. If you feel that this is a "bad idea" or the wrong approach, then don't be afraid to speak your mind. I'd rather find out now, rather than face failure a year from now (but state concrete reasons, rather than "I don't like it" etc.) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std) 2003-05-31 1:35 ` Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std) Warren W. Gay VE3WWG @ 2003-06-01 4:02 ` Randy Brukardt 2003-06-02 16:56 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 27+ messages in thread From: Randy Brukardt @ 2003-06-01 4:02 UTC (permalink / raw) Warren W. Gay VE3WWG wrote in message <3ED806D3.5030001@cogeco.ca>... >While it is too soon to judge general interest in this project, based >upon the pulse of other Ada socket articles in this newsgroup, I think >it is time _something_ was _started_ in this vein. Funding would be >nice, but I don't think we can wait for it. The clock is ticking. > >Rather than lose precious time on this, since defining standards and >reference implementations can require considerable effort, I have >taken some initiative and registered a request at sourcforge for >an ada0Y-net-std project to be created there. The website indicates >that they need 2 business days to review and to respond to the request. Umm, I have to admit that this has been an action item of mine for the last 10 months or so. (See AI-292, which is currently empty). My plan was to put together a group to propose something, but the last time this subject came up here on C.L.A., there wasn't much support for standardizing Sockets. So I put my efforts into decoupling the Claw.Sockets implementation from Claw (and from Windows), so we at least would have a decent library to use, even if not part of the standard. If your goal is to make something for the standard, keep in mind that the important part (and by far the most boring) is writing RM language for the packages. You'll find dozens of people willing to design and critique packages, but you will find hardly anyone ready to write the many pages of RM description needed. Also, if your goal is to get something into the standard, you really have to start with existing practice. There are at least three sockets libraries in current use (Claw sockets [Claw-less version], Gnat sockets, Ada Sockets), and there is no need to design something from scratch. Moreover, you'll get more support from the ARG if you do so, even though the final result probably will differ a lot. >I will be looking for volunteers for various things. I can volunteer >my some of my own time on various things and code, but depending upon >when the submission deadline is, I'll probably need other people to >contribute code and documents as well. Can anyone state when our >ARG submission deadline is? Randy? It depends. For independent outside projects, the deadline is in September. (I don't think that is enough time.) If the project is "invited", the deadline is at the end of December. The easiest way to do that is to convince me that your project is my action item. :-) (Since it's already open and on the agenda, no one can complain about a last-minute addition.) Randy. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std) 2003-06-01 4:02 ` Randy Brukardt @ 2003-06-02 16:56 ` Warren W. Gay VE3WWG 2003-06-03 0:39 ` Randy Brukardt 0 siblings, 1 reply; 27+ messages in thread From: Warren W. Gay VE3WWG @ 2003-06-02 16:56 UTC (permalink / raw) Randy Brukardt wrote: > Warren W. Gay VE3WWG wrote in message <3ED806D3.5030001@cogeco.ca>... ... >>Rather than lose precious time on this, since defining standards and >>reference implementations can require considerable effort, I have >>taken some initiative and registered a request at sourcforge for >>an ada0Y-net-std project to be created there. The website indicates >>that they need 2 business days to review and to respond to the request. > > Umm, I have to admit that this has been an action item of mine for the > last 10 months or so. (See AI-292, which is currently empty). My plan > was to put together a group to propose something, but the last time this > subject came up here on C.L.A., there wasn't much support for > standardizing Sockets. So I put my efforts into decoupling the > Claw.Sockets implementation from Claw (and from Windows), so we at least > would have a decent library to use, even if not part of the standard. ... >>I will be looking for volunteers for various things. I can volunteer >>my some of my own time on various things and code, but depending upon >>when the submission deadline is, I'll probably need other people to >>contribute code and documents as well. Can anyone state when our >>ARG submission deadline is? Randy? > > It depends. For independent outside projects, the deadline is in > September. (I don't think that is enough time.) If the project is > "invited", the deadline is at the end of December. The easiest way to do > that is to convince me that your project is my action item. :-) (Since > it's already open and on the agenda, no one can complain about a > last-minute addition.) > > Randy. Thanks Randy. Based upon the submission deadlines, I think it would be very ambitious to pull anything together for the fall, let alone December, unless someone else wants to lead the charge for this. I was under the mistaken impression that we had a little more time. Thinking about it now, it only makes sense for them to cut it off there. The Source Forge project has been created (I just received confirmation). Is there any interest in producing a networking library that goes beyond sockets? As Randy has pointed out, there are already 3 versions of socket bindings available, and a 4th if you include the partially complete POSIX interface in Florist. I personally favour a library that includes more than just TCP/IP sockets. None of the existing libraries support UNIX sockets yet, that I am aware of (Florist has plans to, but it isn't supported yet). But if there is no interest at all, then it is probably best to drop this project (I am already busy with enough anyway). But if there is _some_ general interest, then we can "chip away at it". We would then have at least 10 years ;-) to develop a working model and have it established. Your comments? -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std) 2003-06-02 16:56 ` Warren W. Gay VE3WWG @ 2003-06-03 0:39 ` Randy Brukardt 2003-06-03 3:47 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy for standardization? (sf:ada0y-net-std) Robert C. Leif 0 siblings, 1 reply; 27+ messages in thread From: Randy Brukardt @ 2003-06-03 0:39 UTC (permalink / raw) Warren W. Gay VE3WWG wrote in message <3EDB81DB.4040503@cogeco.ca>... >Based upon the submission deadlines, I think it would be very ambitious >to pull anything together for the fall, let alone December, unless >someone else wants to lead the charge for this. I was under the mistaken >impression that we had a little more time. Thinking about it now, it >only makes sense for them to cut it off there. Yeah, I was thinking it was further off, too. Time to get to work! >The Source Forge project has been created (I just received confirmation). > >Is there any interest in producing a networking library that goes >beyond sockets? As Randy has pointed out, there are already 3 versions >of socket bindings available, and a 4th if you include the partially >complete POSIX interface in Florist. Tom has been working on such a thing based on Claw.Sockets (minus Claw), but we never came up with a snappy name for it. He has FTP and HTTP client packages (which I've used to save a lot of time on some quicky utilities) and a bunch of other things as well. It would be useful to put together a group to work on it (we'd especially like to see a Linux body for the Sockets packages, because it would help find and eliminate any lingering Window-isms in the package specs) or a similar alternative. It may be best to develop a truly wide-ranging and portable library as a de-facto standard rather than try to get one ready in a few months. Randy. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Provisional Standards was RE: Ada.Networks.Sockets hierarchy for standardization? (sf:ada0y-net-std) 2003-06-03 0:39 ` Randy Brukardt @ 2003-06-03 3:47 ` Robert C. Leif [not found] ` <3EDC8FA6.2000308@noplace.com> 0 siblings, 1 reply; 27+ messages in thread From: Robert C. Leif @ 2003-06-03 3:47 UTC (permalink / raw) To: 'Randy Brukardt', comp.lang.ada We already have a group on building Ada APIs for XML. I believe that I am the Chair. I believe that we should minimize the contents of the Ada standard, yet maximize the contents of standardized Ada libraries. The creation and modification of libraries often is a continuous process. For instance, none of us knows what the detailed structure of XML will be at the end of 5 years. However, we can design a system for creating, what I would call provisional standards, i.e. a binding for which we have a consensus with the understanding that it may have to be changed in the future. An additional virtue of the use of provisional standards is that they can be extensively tested by implementation and use prior to their formally being incorporated into Ada. Parenthetically, I have no strong attachment to the term provisional standard. If there is a better or more precise term, so be it. Bob Leif -----Original Message----- From: Randy Brukardt [mailto:randy@rrsoftware.com] Sent: Monday, June 02, 2003 5:40 PM To: comp.lang.ada@ada.eu.org Warren W. Gay VE3WWG wrote in message <3EDB81DB.4040503@cogeco.ca>... >Based upon the submission deadlines, I think it would be very ambitious >to pull anything together for the fall, let alone December, unless >someone else wants to lead the charge for this. I was under the mistaken >impression that we had a little more time. Thinking about it now, it >only makes sense for them to cut it off there. Yeah, I was thinking it was further off, too. Time to get to work! >The Source Forge project has been created (I just received confirmation). > >Is there any interest in producing a networking library that goes >beyond sockets? As Randy has pointed out, there are already 3 versions >of socket bindings available, and a 4th if you include the partially >complete POSIX interface in Florist. Tom has been working on such a thing based on Claw.Sockets (minus Claw), but we never came up with a snappy name for it. He has FTP and HTTP client packages (which I've used to save a lot of time on some quicky utilities) and a bunch of other things as well. It would be useful to put together a group to work on it (we'd especially like to see a Linux body for the Sockets packages, because it would help find and eliminate any lingering Window-isms in the package specs) or a similar alternative. It may be best to develop a truly wide-ranging and portable library as a de-facto standard rather than try to get one ready in a few months. Randy. ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <3EDC8FA6.2000308@noplace.com>]
* Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) [not found] ` <3EDC8FA6.2000308@noplace.com> @ 2003-06-05 20:48 ` Warren W. Gay VE3WWG 2003-06-06 11:49 ` Marin David Condic ` (3 more replies) 0 siblings, 4 replies; 27+ messages in thread From: Warren W. Gay VE3WWG @ 2003-06-05 20:48 UTC (permalink / raw) Marin David Condic wrote: > I think that when discussing libraries - especially something like XML > that might be in quite a state of flux over the years - that we need a > mechanism different from the ARM. If a "Provisional Standard" committee > were to exist under some auspices that had the cooperation of some > reasonably large subset of the interested players, they could quickly > react to changes in the real world. XML may win or lose as a standard. > It might evolve or be "embraced and extended". New technology may emerge > that makes it obsolete. In this fast paced technological world, nobody > has a crystal ball that can see better than a year in advance. Waiting > for the ARM to react is a guarantee of failure. > > SIGAda is a forum that could serve to develop and maintain a > "Provisional Standard" library. (Isn't that where ASIS originated?) Or > the vendors could form up a research corporation that might even become > self-sustaining if it produced a library that could generate revenue in > the form of support, updates, etc. (Such a research corporation might > even be able to get more developed by volunteers by promising some kind > of royalties for contributions that are accepted.) I think the forum > could be found and the work accomplished, but it needs some kind of > direction and acceptance by the vendors. > > BTW: I agree about the name. If "Provisional Standard" is not > acceptable, go call it "Harold" for all that it matters to me. ;-) > > MDC OK, now that some initial discussion has occurred, is there any further interest in proceeding with the generation of a "provisional standard"? If so, what should it be called, and were would you like to host it? I am going to as SourceForge to remove the project that was set up for me, since it is now inappropriately named (ada0y-net-std). I know there is some casual interest, but is there any real interest in starting a "formal project"? Or is there an existing one that people should be "pointed to"? Warren. > Robert C. Leif wrote: > >> We already have a group on building Ada APIs for XML. I believe that I am >> the Chair. I believe that we should minimize the contents of the Ada >> standard, yet maximize the contents of standardized Ada libraries. The >> creation and modification of libraries often is a continuous process. For >> instance, none of us knows what the detailed structure of XML will be >> at the >> end of 5 years. However, we can design a system for creating, what I >> would >> call provisional standards, i.e. a binding for which we have a consensus >> with the understanding that it may have to be changed in the future. >> >> An additional virtue of the use of provisional standards is that they >> can be >> extensively tested by implementation and use prior to their formally >> being >> incorporated into Ada. >> Parenthetically, I have no strong attachment to the term provisional >> standard. If there is a better or more precise term, so be it. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) 2003-06-05 20:48 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) Warren W. Gay VE3WWG @ 2003-06-06 11:49 ` Marin David Condic 2003-06-06 15:51 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy(Provisional Standard?) Robert C. Leif ` (2 subsequent siblings) 3 siblings, 0 replies; 27+ messages in thread From: Marin David Condic @ 2003-06-06 11:49 UTC (permalink / raw) I would be interested in working on a standard library for Ada (outside the ARM, but considered "Conventional" or "Provisional") However I have a couple of reasonable restrictions: 1) We would be totally wasting our time unless we could get some kind of acceptance from the folks who could put a label on it that says "Official" in some manner. There's some committee covering the Ada standard that should be contacted. There are a handful of vendors out there that have some level of interest in continuing to develop & promote their Ada compilers. They should be contacted. If they say "Yeah, we'll work with you on requirements, stamp as "Official" whatever you produce and see to it that it gets distributed with the compilers...." then you've got something worth working on. Anything else is going to be a failure. Trying to get approval and acceptance on something like this *after* it gets built won't happen. If it will, why hasn't it already happened with one or more of the existing libraries? 2) I am willing to do *some* level of work strictly out of the kindness of my heart and desire to see Ada benefit, but I don't think that level of effort is going to produce anything more than a few toys. If we want to build a *serious* and *credible* library for Ada, it isn't going to happen unless there is some money involved somewhere along the line. I think a scheme could be set up that would make the production of a conventional Ada library something that would pay off. I have some ideas about how that could work. What I believe is this: If there isn't some payment either up front or down the road, nobody is going to devote much time to it and all you'll get is some smallish body of mostly unsupported stuff. If it can be somehow turned into a product that produces some paychecks somewhere along the line, you can then continually grow it into something truly useful and spend time supporting it so that developers will feel comfortable using it. I've got some ideas how this could be made to work. Contact me if you'd like to talk more about it off line. MDC Warren W. Gay VE3WWG wrote: > > I know there is some casual interest, but is there any real interest > in starting a "formal project"? Or is there an existing one that > people should be "pointed to"? > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "In general the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire ====================================================================== ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: Provisional Standards was RE: Ada.Networks.Sockets hierarchy(Provisional Standard?) 2003-06-05 20:48 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) Warren W. Gay VE3WWG 2003-06-06 11:49 ` Marin David Condic @ 2003-06-06 15:51 ` Robert C. Leif 2003-06-07 11:39 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) Marin David Condic 2003-06-10 11:43 ` Marin David Condic 3 siblings, 0 replies; 27+ messages in thread From: Robert C. Leif @ 2003-06-06 15:51 UTC (permalink / raw) To: 'Warren W. Gay VE3WWG', Comp. Lang. Ada At least in the case of XML, we have a mandate to do something. I propose that we start with a "Birds of a Feather" evening meeting at SIGAda 2003. Presently, the only questions are do we start a mailing list and establish a repository? My feeling on the mailing list is, unless our fellow readers of Comp.Lang.Ada decide that no longer want to see comments on this subject, we continue to use Comp.Lang.Ada. The repository is a much more complicated subject, which should be decided upon by those who provide its contents. Bob Leif -----Original Message----- From: Warren W. Gay VE3WWG [mailto:ve3wwg@cogeco.ca] Sent: Thursday, June 05, 2003 1:49 PM To: comp.lang.ada@ada.eu.org Marin David Condic wrote: > I think that when discussing libraries - especially something like XML > that might be in quite a state of flux over the years - that we need a > mechanism different from the ARM. If a "Provisional Standard" committee > were to exist under some auspices that had the cooperation of some > reasonably large subset of the interested players, they could quickly > react to changes in the real world. XML may win or lose as a standard. > It might evolve or be "embraced and extended". New technology may emerge > that makes it obsolete. In this fast paced technological world, nobody > has a crystal ball that can see better than a year in advance. Waiting > for the ARM to react is a guarantee of failure. > > SIGAda is a forum that could serve to develop and maintain a > "Provisional Standard" library. (Isn't that where ASIS originated?) Or > the vendors could form up a research corporation that might even become > self-sustaining if it produced a library that could generate revenue in > the form of support, updates, etc. (Such a research corporation might > even be able to get more developed by volunteers by promising some kind > of royalties for contributions that are accepted.) I think the forum > could be found and the work accomplished, but it needs some kind of > direction and acceptance by the vendors. > > BTW: I agree about the name. If "Provisional Standard" is not > acceptable, go call it "Harold" for all that it matters to me. ;-) > > MDC OK, now that some initial discussion has occurred, is there any further interest in proceeding with the generation of a "provisional standard"? If so, what should it be called, and were would you like to host it? I am going to as SourceForge to remove the project that was set up for me, since it is now inappropriately named (ada0y-net-std). I know there is some casual interest, but is there any real interest in starting a "formal project"? Or is there an existing one that people should be "pointed to"? Warren. > Robert C. Leif wrote: > >> We already have a group on building Ada APIs for XML. I believe that I am >> the Chair. I believe that we should minimize the contents of the Ada >> standard, yet maximize the contents of standardized Ada libraries. The >> creation and modification of libraries often is a continuous process. For >> instance, none of us knows what the detailed structure of XML will be >> at the >> end of 5 years. However, we can design a system for creating, what I >> would >> call provisional standards, i.e. a binding for which we have a consensus >> with the understanding that it may have to be changed in the future. >> >> An additional virtue of the use of provisional standards is that they >> can be >> extensively tested by implementation and use prior to their formally >> being >> incorporated into Ada. >> Parenthetically, I have no strong attachment to the term provisional >> standard. If there is a better or more precise term, so be it. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) 2003-06-05 20:48 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) Warren W. Gay VE3WWG 2003-06-06 11:49 ` Marin David Condic 2003-06-06 15:51 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy(Provisional Standard?) Robert C. Leif @ 2003-06-07 11:39 ` Marin David Condic 2003-06-10 11:43 ` Marin David Condic 3 siblings, 0 replies; 27+ messages in thread From: Marin David Condic @ 2003-06-07 11:39 UTC (permalink / raw) I would be interested in working on a standard library for Ada (outside the ARM, but considered "Conventional" or "Provisional") However I have a couple of reasonable restrictions: 1) We would be totally wasting our time unless we could get some kind of acceptance from the folks who could put a label on it that says "Official" in some manner. There's some committee covering the Ada standard that should be contacted. There are a handful of vendors out there that have some level of interest in continuing to develop & promote their Ada compilers. They should be contacted. If they say "Yeah, we'll work with you on requirements, stamp as "Official" whatever you produce and see to it that it gets distributed with the compilers...." then you've got something worth working on. Anything else is going to be a failure. Trying to get approval and acceptance on something like this *after* it gets built won't happen. If it will, why hasn't it already happened with one or more of the existing libraries? 2) I am willing to do *some* level of work strictly out of the kindness of my heart and desire to see Ada benefit, but I don't think that level of effort is going to produce anything more than a few toys. If we want to build a *serious* and *credible* library for Ada, it isn't going to happen unless there is some money involved somewhere along the line. I think a scheme could be set up that would make the production of a conventional Ada library something that would pay off. I have some ideas about how that could work. What I believe is this: If there isn't some payment either up front or down the road, nobody is going to devote much time to it and all you'll get is some smallish body of mostly unsupported stuff. If it can be somehow turned into a product that produces some paychecks somewhere along the line, you can then continually grow it into something truly useful and spend time supporting it so that developers will feel comfortable using it. I've got some ideas how this could be made to work. Contact me if you'd like to talk more about it off line. MDC Warren W. Gay VE3WWG wrote: I know there is some casual interest, but is there any real interest in starting a "formal project"? Or is there an existing one that people should be "pointed to"? -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "In general the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire ====================================================================== ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) 2003-06-05 20:48 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) Warren W. Gay VE3WWG ` (2 preceding siblings ...) 2003-06-07 11:39 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) Marin David Condic @ 2003-06-10 11:43 ` Marin David Condic 2003-06-10 17:17 ` Warren W. Gay VE3WWG ` (2 more replies) 3 siblings, 3 replies; 27+ messages in thread From: Marin David Condic @ 2003-06-10 11:43 UTC (permalink / raw) I would be interested in working on a standard library for Ada (outside the ARM, but considered "Conventional" or "Provisional") However I have a couple of reasonable restrictions: 1) We would be totally wasting our time unless we could get some kind of acceptance from the folks who could put a label on it that says "Official" in some manner. There's some committee covering the Ada standard that should be contacted. There are a handful of vendors out there that have some level of interest in continuing to develop & promote their Ada compilers. They should be contacted. If they say "Yeah, we'll work with you on requirements, stamp as "Official" whatever you produce and see to it that it gets distributed with the compilers...." then you've got something worth working on. Anything else is going to be a failure. Trying to get approval and acceptance on something like this *after* it gets built won't happen. If it will, why hasn't it already happened with one or more of the existing libraries? 2) I am willing to do *some* level of work strictly out of the kindness of my heart and desire to see Ada benefit, but I don't think that level of effort is going to produce anything more than a few toys. If we want to build a *serious* and *credible* library for Ada, it isn't going to happen unless there is some money involved somewhere along the line. I think a scheme could be set up that would make the production of a conventional Ada library something that would pay off. I have some ideas about how that could work. What I believe is this: If there isn't some payment either up front or down the road, nobody is going to devote much time to it and all you'll get is some smallish body of mostly unsupported stuff. If it can be somehow turned into a product that produces some paychecks somewhere along the line, you can then continually grow it into something truly useful and spend time supporting it so that developers will feel comfortable using it. I've got some ideas how this could be made to work. Contact me if you'd like to talk more about it off line. MDC Warren W. Gay VE3WWG wrote: I know there is some casual interest, but is there any real interest in starting a "formal project"? Or is there an existing one that people should be "pointed to"? -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "In general the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire ====================================================================== ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) 2003-06-10 11:43 ` Marin David Condic @ 2003-06-10 17:17 ` Warren W. Gay VE3WWG 2003-06-11 11:05 ` Marin David Condic 2003-06-10 17:22 ` Warren W. Gay VE3WWG 2003-06-11 6:31 ` AIs for Ada extensions Robert I. Eachus 2 siblings, 1 reply; 27+ messages in thread From: Warren W. Gay VE3WWG @ 2003-06-10 17:17 UTC (permalink / raw) Marin David Condic wrote: > I would be interested in working on a standard library for Ada (outside > the ARM, but considered "Conventional" or "Provisional") Nobody seems to be objecting to this approach. I like the "Provisional" idea myself. > However I have > a couple of reasonable restrictions: > > 1) We would be totally wasting our time unless we could get some kind of > acceptance from the folks who could put a label on it that says > "Official" in some manner. There's some committee covering the Ada > standard that should be contacted. There are a handful of vendors out > there that have some level of interest in continuing to develop & > promote their Ada compilers. They should be contacted. If they say > "Yeah, we'll work with you on requirements, stamp as "Official" whatever > you produce and see to it that it gets distributed with the > compilers...." then you've got something worth working on. Agreed that the end result is to gain general acceptance, and this of course includes the vendors. Do we need this acceptance a priori? I personally don't think so, and I think it would be difficult to do so until there is something to present. We need more than an egg, and something short of a chicken to get there ;-) > Anything else > is going to be a failure. Trying to get approval and acceptance on > something like this *after* it gets built won't happen. This statement (by itself) is just negative thinking. What are the real reasons this "won't happen"? I think this project is like so many others -- we have to prove it and to sell it. Some input is required before we get to that point. I.e. we collectively need to assume some risk to make this happen and start something. > If it will, why > hasn't it already happened with one or more of the existing libraries? There are many reasons and a few of these might include: - people have been focused on language issues (look at all the proposed changes to Ada0Y _language_). - people have been focused on other existing library shortcomings - people have been focused on getting their own job done (we have at least 4 socket implementations that get the job done in some environment, but none are complete or are not completely general.) Largely, I belive it has been one of getting it organized, expending the resources on it, and seeing it through to the end. Take writing a book for an example. It is a monumental task if you look at everything that goes into it. But with many hands, the task gets lighter, even though it is still a major effort. It requires determination and persistence to see it through to the end. It often requires being able to take constructive criticism and having a thick skin at the same time. But many authors manage to do it anyway. I think if we _really_ want to have a standardized result, then _we_ can do it. But we'll need to be determined (as a group). "How badly do we want it?" is basically the question up for discussion at the moment. If we only "sort of" want it, then this does not bode well for the project. > 2) I am willing to do *some* level of work strictly out of the kindness > of my heart and desire to see Ada benefit, That's great, and I think there are a number of others that will do the same. In fact, if the project gets enough momentum, I am sure that even more will become involved at some level or another. > but I don't think that level > of effort is going to produce anything more than a few toys. Why? Linux was a toy in the beginning. If it stays as a toy, then this indicates that the interest in it has languished for some reason or another. Not necessarily because that the idea itself was flawed. > If we want > to build a *serious* and *credible* library for Ada, it isn't going to > happen unless there is some money involved somewhere along the line. Money always helps, no question about it. But a vast amount of software has been contributed without this requirement. If we want a sourced-based UNIX, then things like FreeBSD and Linux are the result. If we _want_ a Ada network library, we _can_ do it without $upport, if we want to. I am not saying that we should turn away support, however. > I > think a scheme could be set up that would make the production of a > conventional Ada library something that would pay off. I think there is a number of interested parties. Wouldn't it be nice if networking were as standardized as Ada.Text_IO? Then your code for Windows, Linux, FreeBSD and whatever would be just one compile away. Your OpenSourced projects can count on a certain implementation of sockets being readily available. I don't need to sell you on this. > I have some ideas > about how that could work. What I believe is this: If there isn't some > payment either up front or down the road, nobody is going to devote much > time to it and all you'll get is some smallish body of mostly > unsupported stuff. declare R1, R2 : Boolean; begin R1 := Small /= Doomed; -- True R2 := Money /= Success; -- True end; > If it can be somehow turned into a product that > produces some paychecks somewhere along the line, you can then > continually grow it into something truly useful and spend time > supporting it so that developers will feel comfortable using it. I think everyone has a vested interest in standardizing the way Ada programs interact with the network. If for no other reason than the saving of time, effort and aggrivation. I think that alone can get us where we want to go with this. It is certainly the one reason I am interested in this. > I've got some ideas how this could be made to work. Contact me if you'd > like to talk more about it off line. > > MDC Perhaps yourself and Bob Leif and I should discuss some ideas offline. I have also received a couple of other quiet notices of interest by email. Let's keep an open mind about how we get there, and try to determine the next steps. Test, debug and reiterate until we succeed. ;-) Any preferences on a mailing list? Perhaps we should start one, to see where this is going. Warren. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) 2003-06-10 17:17 ` Warren W. Gay VE3WWG @ 2003-06-11 11:05 ` Marin David Condic 0 siblings, 0 replies; 27+ messages in thread From: Marin David Condic @ 2003-06-11 11:05 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > > Agreed that the end result is to gain general acceptance, and this > of course includes the vendors. Do we need this acceptance a priori? > I don't think you need their a priori acceptance of anything produced, but you need some acceptance of the notion that some kind of committee or organization is going to be out there producing something that they are expected to accept or endorse in some manner. Otherwise, they are likely to simply wait to see if there is some market demand that they bundle this into their compilers in some way. Then you're back to exactly where we are at with things like the Booch components or a dozen other decent container libraries. Everybody wanting a "standard" container library and no concensus as to which of a dozen available ones it should be. The vendors have to get out front and lead here. > I personally don't think so, and I think it would be difficult to do > so until there is something to present. We need more than an egg, > and something short of a chicken to get there ;-) > If you had the vendors and/or the ARG and/or other interested players willing to say "Look, we've got a library over here that might make a good start and we''re willing to expand on that in some way..." then maybe you can make that work. I'm not suggesting at this point that they have to sign up to either a) accept without review anything produced or b) shell out several million to build it. I'm suggesting that there be some kind of informal understanding that they at least accept the idea of having some group assemble something like a provisional standard library that they would adopt and ship with their compilers. (Or at least point to and call it "Ada") Get a gentleman's agreement that this is a concept they *might* be willing to sign up for should an acceptable product be built and then maybe you can get somewhere. > > This statement (by itself) is just negative thinking. What are the I'm only negative about an approach that doesn't include the Keepers Of The Ada Standard in on the deal. If they are a priori against it, it fails. If they are indiferent to it, it fails. The only possibility of success is if the library becomes such a universally accepted thing without them that they are forced to deal with it. If that was likely, why hasn't it happened with one of the already existing container libraries? > > That's great, and I think there are a number of others that will > do the same. In fact, if the project gets enough momentum, I am > sure that even more will become involved at some level or another. > Such volunteer efforts have been started in the past. They tend to fizzle. I'm not saying it *can't* work - just that it hasn't. Perhaps there is a better approach than a purely voluntary, labor of love, effort? I think so. We could discuss it off line if you like & maybe formulate some ideas together. > > Why? Linux was a toy in the beginning. If it stays as a toy, then > this indicates that the interest in it has languished for some > reason or another. Not necessarily because that the idea itself > was flawed. > For every "Linux" you can point to, I can point to probably several thousand fizzled efforts that have never got beyond being amusing toys. You might get a nice, solid container library out of it, but that is a relatively smallish sort of "toy". A *real* library ought to encompass a rather large range of topics (I have ideas on that as well) and it quickly becomes something bigger than what could be built and maintained by a bunch of part-time volunteers. Or at least unlikely to be built by volunteers and you'd get a hodgepodge of cobbled-together pieces lacking any consistent "theme" and you'd have uncertain maintenance & support. Realistically, I think this needs to be done (or at least picked up by) some organized, funded body - and there are ways to do that without spending a fortune. > > Money always helps, no question about it. But a vast amount of > software has been contributed without this requirement. If we want > a sourced-based UNIX, then things like FreeBSD and Linux are the > result. If we _want_ a Ada network library, we _can_ do it without > $upport, if we want to. I am not saying that we should turn away > support, however. > Why not try to find some support? I think if there is money behind it, it increases the probability of success dramatically. > > Perhaps yourself and Bob Leif and I should discuss some ideas offline. > I have also received a couple of other quiet notices of interest by > email. Let's keep an open mind about how we get there, and try to > determine the next steps. Test, debug and reiterate until we > succeed. ;-) Drop me an e-mail. See my garbled address below. Maybe we can formulate some ideas off line. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "In general the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire ====================================================================== ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) 2003-06-10 11:43 ` Marin David Condic 2003-06-10 17:17 ` Warren W. Gay VE3WWG @ 2003-06-10 17:22 ` Warren W. Gay VE3WWG 2003-06-11 6:31 ` AIs for Ada extensions Robert I. Eachus 2 siblings, 0 replies; 27+ messages in thread From: Warren W. Gay VE3WWG @ 2003-06-10 17:22 UTC (permalink / raw) Marin David Condic wrote: > I would be interested in working on a standard library for Ada (outside > the ARM, but considered "Conventional" or "Provisional") Nobody seems to be objecting to this approach. I like the "Provisional" idea myself. > However I have > a couple of reasonable restrictions: > > 1) We would be totally wasting our time unless we could get some kind of > acceptance from the folks who could put a label on it that says > "Official" in some manner. There's some committee covering the Ada > standard that should be contacted. There are a handful of vendors out > there that have some level of interest in continuing to develop & > promote their Ada compilers. They should be contacted. If they say > "Yeah, we'll work with you on requirements, stamp as "Official" whatever > you produce and see to it that it gets distributed with the > compilers...." then you've got something worth working on. Agreed that the end result is to gain general acceptance, and this of course includes the vendors. Do we need this acceptance a priori? I personally don't think so, and I think it would be difficult to do so until there is something to present. We need more than an egg, and something short of a chicken to get there ;-) > Anything else > is going to be a failure. Trying to get approval and acceptance on > something like this *after* it gets built won't happen. This statement (by itself) is just negative thinking. What are the real reasons this "won't happen"? I think this project is like so many others -- we have to prove it and to sell it. Some input is required before we get to that point. I.e. we collectively need to assume some risk to make this happen and start something. > If it will, why > hasn't it already happened with one or more of the existing libraries? There are many reasons and a few of these might include: - people have been focused on language issues (look at all the proposed changes to Ada0Y _language_). - people have been focused on other existing library shortcomings - people have been focused on getting their own job done (we have at least 4 socket implementations that get the job done in some environment, but none are complete or are not completely general.) Largely, I belive it has been one of getting it organized, expending the resources on it, and seeing it through to the end. Take writing a book for an example. It is a monumental task if you look at everything that goes into it. But with many hands, the task gets lighter, even though it is still a major effort. It requires determination and persistence to see it through to the end. It often requires being able to take constructive criticism and having a thick skin at the same time. But many authors manage to do it anyway. I think if we _really_ want to have a standardized result, then _we_ can do it. But we'll need to be determined (as a group). "How badly do we want it?" is basically the question up for discussion at the moment. If we only "sort of" want it, then this does not bode well for the project. > 2) I am willing to do *some* level of work strictly out of the kindness > of my heart and desire to see Ada benefit, That's great, and I think there are a number of others that will do the same. In fact, if the project gets enough momentum, I am sure that even more will become involved at some level or another. > but I don't think that level > of effort is going to produce anything more than a few toys. Why? Linux was a toy in the beginning. If it stays as a toy, then this indicates that the interest in it has languished for some reason or another. Not necessarily because that the idea itself was flawed. > If we want > to build a *serious* and *credible* library for Ada, it isn't going to > happen unless there is some money involved somewhere along the line. Money always helps, no question about it. But a vast amount of software has been contributed without this requirement. If we want a sourced-based UNIX, then things like FreeBSD and Linux are the result. If we _want_ a Ada network library, we _can_ do it without $upport, if we want to. I am not saying that we should turn away support, however. > I > think a scheme could be set up that would make the production of a > conventional Ada library something that would pay off. I think there is a number of interested parties. Wouldn't it be nice if networking were as standardized as Ada.Text_IO? Then your code for Windows, Linux, FreeBSD and whatever would be just one compile away. Your OpenSourced projects can count on a certain implementation of sockets being readily available. I don't need to sell you on this. > I have some ideas > about how that could work. What I believe is this: If there isn't some > payment either up front or down the road, nobody is going to devote much > time to it and all you'll get is some smallish body of mostly > unsupported stuff. declare R1, R2 : Boolean; begin R1 := Small /= Doomed; -- True R2 := Money /= Success; -- True end; > If it can be somehow turned into a product that > produces some paychecks somewhere along the line, you can then > continually grow it into something truly useful and spend time > supporting it so that developers will feel comfortable using it. I think everyone has a vested interest in standardizing the way Ada programs interact with the network. If for no other reason than the saving of time, effort and aggrivation. I think that alone can get us where we want to go with this. It is certainly the one reason I am interested in this. > I've got some ideas how this could be made to work. Contact me if you'd > like to talk more about it off line. > > MDC Perhaps yourself and Bob Leif and I should discuss some ideas offline. I have also received a couple of other quiet notices of interest by email. Let's keep an open mind about how we get there, and try to determine the next steps. Test, debug and reiterate until we succeed. ;-) Any preferences on a mailing list? Perhaps we should start one, to see where this is going. Marin, perhaps you can send me your email address. Warren. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 27+ messages in thread
* AIs for Ada extensions 2003-06-10 11:43 ` Marin David Condic 2003-06-10 17:17 ` Warren W. Gay VE3WWG 2003-06-10 17:22 ` Warren W. Gay VE3WWG @ 2003-06-11 6:31 ` Robert I. Eachus 2003-06-11 11:08 ` Marin David Condic 2003-06-12 1:10 ` Alexander Kopilovitch 2 siblings, 2 replies; 27+ messages in thread From: Robert I. Eachus @ 2003-06-11 6:31 UTC (permalink / raw) Marin David Condic wrote: > 1) We would be totally wasting our time unless we could get some kind of > acceptance from the folks who could put a label on it that says > "Official" in some manner. There's some committee covering the Ada > standard that should be contacted. There are a handful of vendors out > there that have some level of interest in continuing to develop & > promote their Ada compilers. They should be contacted. If they say > "Yeah, we'll work with you on requirements, stamp as "Official" whatever > you produce and see to it that it gets distributed with the > compilers...." then you've got something worth working on. Anything else > is going to be a failure. Trying to get approval and acceptance on > something like this *after* it gets built won't happen. If it will, why > hasn't it already happened with one or more of the existing libraries? The right thing to do here is to get busy and catch up on the proposed new packages in Ada0Y. They can be found in the AIs at http://www.ada-auth.org/ais.html I made up a list of the extension AI's I am aware of--Bob and Randy should let me know if I missed any. Of course, in many cases whether an AI is a "normal" AI fixing something that is broken or a suggested extension is hard to characterize. Also some of the AI's listed as "other than packages may end up as extension packages and vice-versa. AI-234 for example may end up being resolved by having an explicit package that defines a "true" unsigned integer type. (Or such a type may end up in package System, System.Address often is such a type.) Some things to keep in mind if you want to read these AIs and comment. 1) Not all of these AIs will end up in Ada0Y or whatever you want to call it. AI-323 is a good example of something that won't make it. 2) Read the AIs thoroughly before sending comments to the ARG. If you are not sure whether to post here or to the ARG or the Ada-Comment list, post here. There are several ARG members who read this list regularly. If your post should go to the ARG, we will either suggest you send it, or forward it. 3) There will be a meeting of the ARG in just over a week. Fifteen extension AIs are on the preliminary agenda. So some of these AIs will change drastically in a couple of weeks. 4) If you do have constructive comments, be very specific. The more detail in your comments, the more they will be listened to. I think there should be a package for ZZZ is not useful. I think this package (see listing below with explantion) should be made part of the standard, is more likely to be listened to--and result in lots of other comments. 5) If you want to submit a new package proposal, go ahead. But have a package you use for a rough proposal at least. "Wouldn't it be nice to have..." doesn't belong in the standard. (If you do have a package that your group and several other groups uses, those are good candidates for inclusion.) If you have thin skin or a big ego think carefully before sticking your head up. People don't get attacked at ARG meetings or on the ARG list, but ideas get sliced into shreds--often by the original author. (Think of submitting ideas to the ARG as akin to throwing a chunk of meat to a well-trained sled dog team. The dogs may be nice to each other, but the meat is going to get torn to shreds and thrown around a lot.) Eventually, of course, all of the potential issues have been dealt with, and the final proposal may look nothing like the original. At that point the ARG will move on to the next AI. This is necessary. You don't want half-baked or changes that were not thoroughly examined added to the language. But it also means that many people are best off submitting ideas to the ARG through filters (like this newsgroup). If half a dozen people agree on a particular package specification, it might not get torn up too badly by the ARG. But more important, if you are not the only author, you won't take the criticism so personally. So if you want to participate read the e-mail comments on some of these AIs. You may then want to arrange to be invited to an ARG meeting. If you survive the meeting, you may even want to join. Feeling mentally wrung out at the end of a meeting is nothing to worry about. It means you were actually following the discussions. Some of these AIs take more than a day to fully understand, and the ARG often deals with more than a dozen per day. Of course, some AIs go through several meetings before they are finished. Some issues are best dealt with in a meeting, others are better handled by e-mail. So a typical resolution is for the ARG to accept a set of revisions "in principle," delegate revising the AI to someone. This will be discussed by e-mail and then either an e-mail vote is taken, or it goes on the agenda for.the next meeting (again). Proposed new packages: AI-248 Directory Operations AI-282 Ada unit information symbols AI-292 Sockets Operations (Has a general discussion about standarizing new packages.) AI-296 Vector and matrix operations AI-297 Timing Events AI-301 Missing operations in Ada.Strings.Unbounded AI-302 Data structure components for Ada AI-307 Execution-Time Clocks AI-324 Physical Units Checking Language Extenstions for Ada0Y other than packages: AI-217 Handling Mutually Dependent Type Definitions that Cross Packages (See also AI-10217, AI-20217, AI-30217, AI-40217 and AI 50217) AI-218 Accidental overloading when overriding (See also AI-10218) AI-222 Feature control AI-224 pragma Unsuppress AI-230 Generalized use of anonymous access types AI-231 Access-to-constant parameters and null-excluding subtypes AI-234 Unsigned integer types AI-249 Ravenscar profile for high-integrity systems AI-250 Protected Types, Extensible, Tagged, Abstract AI-251 Abstract Interfaces to provide Multiple Inheritance AI-252 Object.Operation Notation AI-254 Downward closures for access to subprogram types AI-257 Restrictions for implementation-defined entities AI-260 How to control the tag representation in a stream AI-261 Extending enumeration types AI-262 Access to private units in the private part AI-264 Exceptions as Types AI-265 Partition Elaboration Policy for High-Integrity Systems AI-266 Task Termination procedure (See also AI-10266) AI-267 Fast float-to-integer conversions AI-270 Stream item size control AI-274 Requiring complete record representation clauses AI-281 Representation of enumeration type image attribute AI-284 Nonreserved keywords AI-285 Support for 16-bit and 32-bit characters AI-286 Assert pragma AI-287 Limited Aggregates Allowed AI-288 Pre/Postconditions and Invariants AI-290 Declaring functions Pure AI-294 Built-in hash function AI-298 Non-Preemptive Dispatching AI-299 Defaults for generic formal parameters AI-300 The standard storage pool AI-305 Data structure components for Ada AI-310 Ignore abstract nondispatching subprograms during overloading AI-314 Standardize Discard_Names AI-315 Full support for IEEE 754 AI-317 Partial Parameter Lists for Formal Packages AI-318 Object_Size attribute AI-322 User-defined operator symbols AI-323 Allow in out parameters for functions (Status No Action, and that is highly unlikely to change.) AI-325 Anonymous access types as function result types (depends on AI-230) AI-326 Tagged incomplete types AI-327 Dynamic Ceiling Priorities ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AIs for Ada extensions 2003-06-11 6:31 ` AIs for Ada extensions Robert I. Eachus @ 2003-06-11 11:08 ` Marin David Condic 2003-06-12 1:10 ` Alexander Kopilovitch 1 sibling, 0 replies; 27+ messages in thread From: Marin David Condic @ 2003-06-11 11:08 UTC (permalink / raw) It wouldn't hurt to get up to date with what the ARG is discussing in the way of libraries. The ARG might even be the proper keeper of a "provisional standard" - or at least an interested party in how that works out. My only caution is that tying a library too closely to a standards body might slow down or otherwise restrict what an Ada library might do. MDC Robert I. Eachus wrote: > > > The right thing to do here is to get busy and catch up on the proposed > new packages in Ada0Y. They can be found in the AIs at > http://www.ada-auth.org/ais.html I made up a list of the extension AI's -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "In general the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire ====================================================================== ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AIs for Ada extensions 2003-06-11 6:31 ` AIs for Ada extensions Robert I. Eachus 2003-06-11 11:08 ` Marin David Condic @ 2003-06-12 1:10 ` Alexander Kopilovitch 2003-06-12 17:19 ` Robert I. Eachus 1 sibling, 1 reply; 27+ messages in thread From: Alexander Kopilovitch @ 2003-06-12 1:10 UTC (permalink / raw) Robert I. Eachus wrote: >The right thing to do here is to get busy and catch up on the proposed >new packages in Ada0Y. >... >Proposed new packages: >... >AI-302 Data structure components for Ada >... >Language Extenstions for Ada0Y other than packages: >... >AI-251 Abstract Interfaces to provide Multiple Inheritance >... It seems to be an unfortunate collision that multiple new packages should be proposed when Abstract Interfaces still aren't established firmly. It is highly likely that some packages (for example, Data structures components) may look significantly better if they can use Abstract Interfaces. But one can't expect "widely used" prototype interface-based packages for standartization until Abstract Interfaces went into practice in Ada. So, perhaps, standartization of packages that can significantly benefit from Abstract Interfaces should be delayed, and follow the Core standard after year or two. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AIs for Ada extensions 2003-06-12 1:10 ` Alexander Kopilovitch @ 2003-06-12 17:19 ` Robert I. Eachus 2003-06-13 1:02 ` Alexander Kopilovitch 0 siblings, 1 reply; 27+ messages in thread From: Robert I. Eachus @ 2003-06-12 17:19 UTC (permalink / raw) Alexander Kopilovitch wrote: > It seems to be an unfortunate collision that multiple new packages should be > proposed when Abstract Interfaces still aren't established firmly. > It is highly likely that some packages (for example, Data structures > components) may look significantly better if they can use Abstract Interfaces. > But one can't expect "widely used" prototype interface-based packages for > standartization until Abstract Interfaces went into practice in Ada. > So, perhaps, standartization of packages that can significantly benefit > from Abstract Interfaces should be delayed, and follow the Core standard > after year or two. I personally don't see any conflict. The interface AI will allow easier bindings to C++ and Java. But in Ada, mix-ins are a better abstraction IMHO for containers. The advantage is that you can easily put objects in a container even if the original declarer of the type/class had no idea that they would be put in a container. For example: with Ada.Containers.AVL_Tree; generic type Member is private; with function Index(E: Element) return String; Null_Entry: Member; package Dictionaries is type Dictionary is limited private; function Lookup (Key: in String) return Member; function Add (M: in Member); ... private type Dictionary is new Ada.Containers.AVL_Tree(Member,...); ... end Dictionaries; (No arguments about how to better do this, please. This is just an expository example) Notice that using mix-in containers, the type Member doesn't have to "know" that it could be added to a Dictionary. The actual dictionary entry will in effect be a child of Member and AVL_Trees.Tree. But Member doesn't even have to be a tagged type... ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AIs for Ada extensions 2003-06-12 17:19 ` Robert I. Eachus @ 2003-06-13 1:02 ` Alexander Kopilovitch 2003-06-13 7:21 ` Robert I. Eachus 0 siblings, 1 reply; 27+ messages in thread From: Alexander Kopilovitch @ 2003-06-13 1:02 UTC (permalink / raw) Robert I. Eachus wrote: > > It seems to be an unfortunate collision that multiple new packages should be > > proposed when Abstract Interfaces still aren't established firmly. > > It is highly likely that some packages (for example, Data structures > > components) may look significantly better if they can use Abstract Interfaces. > >I personally don't see any conflict. The interface AI will allow easier >bindings to C++ and Java. But in Ada, mix-ins are a better abstraction >IMHO for containers. The advantage is that you can easily put objects >in a container even if the original declarer of the type/class had no >idea that they would be put in a container. For example: >... Yes, but what about similar containers, such as various flavors of List? And it is not an easy task to align properly the above your words with another your opinion (with which I fully agree), posted here about 3 weeks ago - I mean the following: >Date: Thu, 29 May 2003 02:22:22 GMT >Subject: Re: Problem space and solution space > >... In Ada you tend not to have one sort >package in your toolbox, or one list type implementation, you have >several. Now the programmer solving some problem sees a part of his >decomposition that can be solved by a list package or a sort package, >and does a generic instantiation. The problem is that there is no easy >way, in Ada, to express a binding to a member of the class of sort >generics, but to delay the choice of the actual mapping. > >This is why one of the features I expect interfaces to add to Ada is a >better way of organizing collections of sort algorithms and the like. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AIs for Ada extensions 2003-06-13 1:02 ` Alexander Kopilovitch @ 2003-06-13 7:21 ` Robert I. Eachus 2003-06-13 21:53 ` tmoran 2003-06-14 23:30 ` Alexander Kopilovitch 0 siblings, 2 replies; 27+ messages in thread From: Robert I. Eachus @ 2003-06-13 7:21 UTC (permalink / raw) Alexander Kopilovitch wrote: > Robert I. Eachus wrote: > > >>>It seems to be an unfortunate collision that multiple new packages should be >>>proposed when Abstract Interfaces still aren't established firmly. >>>It is highly likely that some packages (for example, Data structures >>>components) may look significantly better if they can use Abstract Interfaces. >> >>I personally don't see any conflict. The interface AI will allow easier >>bindings to C++ and Java. But in Ada, mix-ins are a better abstraction >>IMHO for containers. The advantage is that you can easily put objects >>in a container even if the original declarer of the type/class had no >>idea that they would be put in a container. For example: >>... > Yes, but what about similar containers, such as various flavors of List? > And it is not an easy task to align properly the above your words with another > your opinion (with which I fully agree), posted here about 3 weeks ago - > I mean the following: >>... In Ada you tend not to have one sort >>package in your toolbox, or one list type implementation, you have >>several. Now the programmer solving some problem sees a part of his >>decomposition that can be solved by a list package or a sort package, >>and does a generic instantiation. The problem is that there is no easy >>way, in Ada, to express a binding to a member of the class of sort >>generics, but to delay the choice of the actual mapping. >> >>This is why one of the features I expect interfaces to add to Ada is a >>better way of organizing collections of sort algorithms and the like. Real subtle point. Interfaces as currently planned will ALLOW multiple interface inheritance. They can also be used as I described in the first paragraph to provide multiple instances of a single abstract interface. I expect the multiple (interface) inheritance use to be common when interfacing to code written in other OO languages. The usage I described is almost not a programming convention but a way to describe the relationship between a number of otherwise unrelated abstractions. They all implement the same interface, so they can be passed to generics as instances of that interface, but otherwise there is no necessary relation between the abstractions. Can you use multiple interface inheritance to describe abstractions that match more than one interface? Sure, and it will happen. For example imagine an AVL_Tree package which clearly allows random (indexed) access, and also has an ability to do an inorder walk. It can also implement the list interface. The question is whether it will be common. The problem becomes a programming in the large issue. It is going to be much easier to create a list 'view' of the AVL_Tree package and keep it consistant with the list interface, than to maintain a package that directly implements multiple interfaces. This is probably a very good example, so let me follow it through a bit. generic type Element is private; package Lists is type List is abstract interface; function Head(L: in List) return Element; function Is_Empty(L: in List) return Boolean; procedure Append(L: in out List; E: in Element); type Iterator is private with null; function Create(L: in List) return Iterator; function Next(I: in Iterator) return Element; function At_End(I: in Iterator) return Boolean; private ... end Lists; I did the iterator this way because it brings up an interesting question about interface types. Obviously an instance of the Lists package also creates a new Iterator type, and that type is closely related to type List. But are functions like Next and At_End part of the List interface? I think it is an issue AI-251 needs to address. Now I want to create a binding between this interface and a tree type. The package spec is easy: with Lists; generic with package Trees is new AVL_Trees; -- Could make the element type explicit, but no reason to, it is -- already specifed by the element type in the AVL_Trees instance. package List_View is type List is private with null; function Head(L: in List) return Element; function Is_Empty(L: in List) return Boolean; procedure Append(L: in out List; E: in Element); type Iterator is private with null; function Create(L: in List) return Iterator; function Next(I: in Iterator) return Element; function At_End(I: in Iterator) return Boolean; private type List is Trees.AVL_Tree; type Iterator is Trees.Inorder_Walk with null; end List_View; Now it gets tough. Not because it is hard to write, but their is one tough decision. Head is fairly easy to write, start at the root of the tree and follow left links until you find one that is null. The contents of that node are what you want to return. Is_Empty and the Iterator operations shouldn't be too hard, since I specified that AVL_Trees provides an inorder walk interator. But what to do about Append? I see three options: 1) Always raise Program_Error. In other words, this is just a view, and not a full list implementation. 2) Raise an error if the new Element does go at the end of the list. Err, tree. This allows the Append operation to be used to insert a sorted set of Elements one at a time. 3) Insert the Element at the proper position in the tree, and invalidate any existing Iterators, that are past the position the new Element will be inserted in, either in the implementation or by fiat. (In other words, document it as an error to insert with an open Iterator.) Whichever solution you choose, all done. Notice that we have created a binding between one abstraction Lists, and another, AVL_Trees, that never explicitly uses the new interface feature to implement multiple inheritance. We could have done it, but some of the List operations only loosely make sense for an AVL_Tree viewed as a tree (the Head operation) while others will be hidden by the interface entirely. It may be that some of the operations for the List view may perfectly match the available operations for the AVL_Tree (Is_Empty?), but many will have different names. So what? The "overhead" of making the list view explicit makes maintenance much easier. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AIs for Ada extensions 2003-06-13 7:21 ` Robert I. Eachus @ 2003-06-13 21:53 ` tmoran 2003-06-14 23:30 ` Alexander Kopilovitch 1 sibling, 0 replies; 27+ messages in thread From: tmoran @ 2003-06-13 21:53 UTC (permalink / raw) If Interfaces are like the Interfaces in MS Windows dll's, the question arises: how often do different dll's reuse non-root interfaces? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AIs for Ada extensions 2003-06-13 7:21 ` Robert I. Eachus 2003-06-13 21:53 ` tmoran @ 2003-06-14 23:30 ` Alexander Kopilovitch 1 sibling, 0 replies; 27+ messages in thread From: Alexander Kopilovitch @ 2003-06-14 23:30 UTC (permalink / raw) Robert I. Eachus wrote: >... >Notice that we have created a >binding between one abstraction Lists, and another, AVL_Trees, that >never explicitly uses the new interface feature to implement multiple >inheritance. >... >The "overhead" of making the list view >explicit makes maintenance much easier. Yes, all that is fine. But I was much more concerned with basic use of abstract interfaces (such as in your AVL_Trees example) for containers than with multiple inheritance. Anyway, now after reading (and rereading -:) your posting, I think that I got what I wanted: there is a chance that ARG will pay some attention to the interactions between AI-251 and AI-302, and will not consider them as completely independent from each other. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Ada.Networks.Sockets hierarchy for standardization? 2003-05-31 17:24 ` Michael Erdmann 2003-05-31 1:35 ` Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std) Warren W. Gay VE3WWG @ 2003-05-31 23:47 ` Warren W. Gay VE3WWG 2003-06-01 7:07 ` Michael Erdmann 1 sibling, 1 reply; 27+ messages in thread From: Warren W. Gay VE3WWG @ 2003-05-31 23:47 UTC (permalink / raw) Michael Erdmann wrote: > Warren W. Gay VE3WWG wrote: > >> For discussion: I have thrown together this evening >> a more formalized view of some "chicken scratching" I did on my >> train commute home this evening. The diagram is available at my >> web site (see PDF link further on). > > I like it. But may be the names services should be put under > Services. Hi Michael: The problem that I see is that there is a fairly major distinction between DNS (Name_Services) and what Ada.Network.Services.Internet represents. The later represents a database of mappings between numeric port numbers (services) and their names (ie. "http" maps to port 80). Name_Services is much more than that. It is an entire protocol built upon the transport(s) (DNS uses UDP and TCP/IP), and in the case of DNS, it is distributed and fairly complex in operation. There are also different name services, and X.500 represents another from the OSI model. So if you move these, then I think they should either be grouped under "name services" or put underneath the general set of protocols built upon. But I personally like to group name services together, because they represent one major "category" of network function. Maybe an improvement might be to move "Ada.Networks.Services" over to child package Ada.Networks.Protocols.Internet.Services instead (these would only be Internet specific of course). Alternatively, it would be tempting to just merge it right into the package Ada.Networks.Protocols.Internet. The mappings for ports and the protocol selection constants aren't that far apart in concept. Other protocols like X.25, may not even need a "services" package. Its been years since I used Datapac (X.25), but IIRC there is no concept of a port. You just use a DNIC (address) and perhaps select the service once you connect to the host at the remote end. Perhaps the service selection is embedded in the DNIC (I forget). OTOH, the amateur radio protocol AX.25, which is based upon X.25, does support up to 16 ports (I forget now, but one of these 16 may be reserved). Take a look at the v2 document below: http://home.cogeco.ca/~ve3wwg/Ada.Networks_Hierarchy_v2.pdf Here I moved Services (in blue) underneath Ada.Networks.Protocols.Internet. I think that perhaps that child package might be best merged into Internet, but what do you'all think? I still think Naming services should remain distinct, and probably underneath Ada.Networks somewhere, though package names and overall organizaton are certainly open for more discussion. Is there a better name for Name_Services? Should this be Directory or Directory_Services? > Maybe i have missed it, but what is the difference between red > and black boxes? > > Michael The red just indicated what I believe should be a minimum effort for a "complete" implementation. The blue in the link above, is just to highlight the change. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Ada.Networks.Sockets hierarchy for standardization? 2003-05-31 23:47 ` Ada.Networks.Sockets hierarchy for standardization? Warren W. Gay VE3WWG @ 2003-06-01 7:07 ` Michael Erdmann 0 siblings, 0 replies; 27+ messages in thread From: Michael Erdmann @ 2003-06-01 7:07 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Michael Erdmann wrote: > >> Warren W. Gay VE3WWG wrote: >> >>> For discussion: I have thrown together this evening >>> a more formalized view of some "chicken scratching" I did on my >>> train commute home this evening. The diagram is available at my >>> web site (see PDF link further on). >> >> >> I like it. But may be the names services should be put under >> Services. > > > Hi Michael: > > The problem that I see is that there is a fairly major > distinction between DNS (Name_Services) and what > Ada.Network.Services.Internet represents. The later represents > a database of mappings between numeric port numbers (services) > and their names (ie. "http" maps to port 80). > It makes sense. But i gues these service identifiers may have to be a little more generalized, for example as SAPI. > Name_Services is much more than that. It is an entire protocol .................. > > Maybe an improvement might be to move "Ada.Networks.Services" over > to child package Ada.Networks.Protocols.Internet.Services > instead (these would only be Internet specific of course). I think this is a better idea, since the semantic of what is a service verry mutch depends on the doain or protocol stack you are looking at. > Alternatively, it would be tempting to just merge it right > into the package Ada.Networks.Protocols.Internet. The mappings > for ports and the protocol selection constants aren't that > far apart in concept. > > Other protocols like X.25, may not even need a > "services" package. I do not understand this. You can run FTAM on top of X.25 which is a service. I gues it would a a good idea to give the term Service a clear definition which fits into the OSI Model. Its been years since I used Datapac (X.25), > but IIRC there is no concept of a port. You just use a DNIC > (address) and perhaps select the service once you connect to the > host at the remote end. Perhaps the service selection is > embedded in the DNIC (I forget). OTOH, the amateur radio > protocol AX.25, which is based upon X.25, does support up to > 16 ports (I forget now, but one of these 16 may be reserved). > This is the reason why i think, the better idea is to place the service identifiers alsways near to the protocol stack/domain they are refering to. Michael > ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2003-06-14 23:30 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-05-31 5:01 Ada.Networks.Sockets hierarchy for standardization? Warren W. Gay VE3WWG 2003-05-31 6:33 ` Tarjei T. Jensen 2003-05-31 13:35 ` Simon Wright 2003-05-31 17:24 ` Michael Erdmann 2003-05-31 1:35 ` Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std) Warren W. Gay VE3WWG 2003-06-01 4:02 ` Randy Brukardt 2003-06-02 16:56 ` Warren W. Gay VE3WWG 2003-06-03 0:39 ` Randy Brukardt 2003-06-03 3:47 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy for standardization? (sf:ada0y-net-std) Robert C. Leif [not found] ` <3EDC8FA6.2000308@noplace.com> 2003-06-05 20:48 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) Warren W. Gay VE3WWG 2003-06-06 11:49 ` Marin David Condic 2003-06-06 15:51 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy(Provisional Standard?) Robert C. Leif 2003-06-07 11:39 ` Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?) Marin David Condic 2003-06-10 11:43 ` Marin David Condic 2003-06-10 17:17 ` Warren W. Gay VE3WWG 2003-06-11 11:05 ` Marin David Condic 2003-06-10 17:22 ` Warren W. Gay VE3WWG 2003-06-11 6:31 ` AIs for Ada extensions Robert I. Eachus 2003-06-11 11:08 ` Marin David Condic 2003-06-12 1:10 ` Alexander Kopilovitch 2003-06-12 17:19 ` Robert I. Eachus 2003-06-13 1:02 ` Alexander Kopilovitch 2003-06-13 7:21 ` Robert I. Eachus 2003-06-13 21:53 ` tmoran 2003-06-14 23:30 ` Alexander Kopilovitch 2003-05-31 23:47 ` Ada.Networks.Sockets hierarchy for standardization? Warren W. Gay VE3WWG 2003-06-01 7:07 ` Michael Erdmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox