OSLib 6.11 Released

[Jonathan Coxhead]

   On 28 Sep 00, Chris Rutter wrote,

 | On Wed, 27 Sep 2000, Jonathan Coxhead wrote:
 | 
 | >    That seems very nice all round. Any downside?
 | 
 | Only that I think I prefer the merge-into-one-directory solution.

   I agree with Tony that installation should be kept as simple as 
possible. Since you came up with a way of preserving the "clean" source 
code interface

      #include "oslib/os.h"

while keeping the 4-part structure internally, I don't see any reason to 
throw away the useful facility of being able to install on pre-RISC O S 4 
ADFS discs.

 | The whole 77 limit is just an embarassment: raFS convincingly solves
 | the problem on those discs or operating systems where the problem
 | still remains, however: I feel it reasonable to tell the user `install
 | this on a proper filesystem', and let them sort out whether they wish
 | to use a soft-load FileCore, X-Files, raFS, NFS, or whatever -- that
 | isn't something OSLib should get involved in (other than maybe
 | suggesting where to find some example programs).

   Nothing we're going to do prevent people from using raFS etc.

 | The people installing
 | OSLib should be capable, competent software engineers: people more than
 | capable of rigging up an NFS server, an raFS directory, or whatever -- if
 | they haven't done already, which I believe the overwhelming majority of
 | technically-savvy RISC OS users have.

   This is lunacy! You can't make decisions based on who "should be" using 
the software, but on who *is* using it.

 | I'm fairly strongly convinced that unless the `Core' &c. directories
 | feature in the #include statement, they shouldn't exist in the
 | filesystem either.  If there's a good reason (and not just expediency
 | of a geriatric filing system) to segregate them, then I believe they
 | probably /should/ feature in the #include directive, and that the
 | namespaces should be defined as discrete, so that portions of one
 | module belonging in one part of the library can be implement separately
 | from another.

   I'd say that "expediency of a geriatric filing system" *was* a reason---
and a very good one (albeit expresed in somewhat colourful language!).

 | The fact that this isn't especially necessary -- we have a non-clashing
 | namespace defined for us by RISC OS right from the start, anyway -- 
suggests
 | to me that in fact the headers /should not/ be segregated.

   It harms no-one, and benefits a few. So how about we leave it as is?