Re: Ada package registry?

[Georg Bauhaus <bauhaus@futureapps.invalid>]

On 07.02.16 20:54, Dmitry A. Kazakov wrote:
> An access to execute SELECT on a DB table is no different to an ability to view the table in Excel or any other program.


This kind of access is a no-go area in some organisations.
No one, including own employees, may know the names of tables;
or even learn if there is an RDMBS at all. Let alone enjoy the
privileges of learning about the particulars of the databases.

An Excel table is a passive data entity, and a document(!).
It is an entity that is separate from the DBMS and therefore
leaks nothing about the database, and imposes no risk of a broken
security setup. Shit happens, some want to avoid that by putting
databases behind walls.  Database programs will produce documents
to be forwarded, after checking and signing.

You could call these considerations "abstraction" between commercial
entities or other organisations, or individuals.

I'd be very surprised if I could go to my bank and ask
them about their database schema, and be told it! Or ask Google
about the ad network's databases from which they produce the CSVs
that they send, and be given read-only access.

It is at this level of organisational design that I meant to put the
analogy of dropping Ada's "private".  "Body" could mean, by analogy,
that you will get to see something at some interface level, but no bodies!
As a user of the spec, you'd know absolutely nothing about bodies,
compiled or not.

Database schemas, like bodies, can be declared to be part of corporate
property, by the powers that be.

Even interfaces can be part of corporate property: I understand that
some legal initiative is on its way in order to get a decision on whether
a collection of type's interfaces (names, patterns, etc. of a framework)
can be put under copyright law or some such. It takes some effort to produce
one, after all, so the logical consequence from BA theory is obvious:
prevent copying OS interfaces, for example, by disallowing the use of
the same names in APIs.