From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,39579ad87542da0e X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 X-Received: by 10.68.191.36 with SMTP id gv4mr5401216pbc.8.1368647950592; Wed, 15 May 2013 12:59:10 -0700 (PDT) Path: bp1ni2404pbd.1!nntp.google.com!news.glorb.com!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 15 May 2013 14:59:10 -0500 Newsgroups: comp.lang.ada Date: Wed, 15 May 2013 15:59:07 -0400 From: "Peter C. Chapin" X-X-Sender: peter@whirlwind Subject: Re: Seeking for papers about tagged types vs access to subprograms In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-EKWjg+HurasHhEFR/u1Amwd5q8xeCjwoF2GzIuhWA9gHjhs6KykKVRpCp3MCqwQG5lvDSVo4A5auchZ!VUGyGT3OU7vxXV6247tjrcdRahDrzDy2KiaqvKvR31O8/aoidroHMor5Dl0WC64iC3Z1OsxvbQ== X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 4367 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Date: 2013-05-15T15:59:07-04:00 List-Id: On Wed, 15 May 2013, Yannick Duch=C3=AAne (Hibou57) wrote: > I may see a better options: what about multiple views for a file? File=20 > view drivers? Query interface to query what interface(s)/view(s) a file= =20 > provides? A standard format to describe interfaces? Standardisation of a= =20 > basic set of very common interface (which may be completed as the=20 > technologies evolves)? > > Pushing this kind of responsibility to the applications, is the surest=20 > way to have a mess of non=E2=80=91interoperable things, wasting duplicate= s,=20 > inconsistencies, data corruption, applications guessing all the time,=20 > etc (and that's indeed how it goes so far). I understand what you're saying. The issue ultimately comes down to=20 deciding how high up the chain of abstraction one expects the operating=20 system to go. We can probably all agree that the OS should be responsible= =20 for managing the hardware itself (via device drivers). We can also=20 probably all agree that the application should deal with problems that are= =20 unique to it. Yet who should deal with the structure of, say, a JPEG image? Should every= =20 application that wants to manipulate such images duplicate the code=20 required to do so? Should the OS materialize the "JPEG file" abstraction=20 directly in its API? Of course in the real world JPEG images are manipulated by a library that= =20 multiple applications can use. Thus while the code *is* duplicated in=20 each process as far as the OS can see, the programmers are not really=20 writing that code freshly every time. In fact, in many systems that code=20 could reside in a shared library... a kind of gray zone between the=20 application and the OS. Any OS that tried to provide a specialized JPEG file type is biting off a= =20 lot. It would be taking on the responsibility of providing every kind of=20 specialized file type that could ever exist. To do that it would have to=20 provide a low level "sequence of bytes" abstraction along with some kind=20 of extension mechanism (shared libraries?) to allow users to add on the=20 support they need. Isn't that what we have now, more or less? Peter