| After reading a comment in another thread (which I cannot now find), I think I
see an legal analogy to API> The other comment pointed out that an interface
is a boundary, an abstract, notional surface or line where two 'things'
contact and maybe interact without losing either identity on their respective
'sides' of the boundary.
That's the normal meaning of an interface; but in
legal jargon, a boundary may also have have easements, through the
boundary and 'over' the stuff on the other side. An easement, like a license,
is a permissible violation of a boundary or prohibition. That's what's
important about an API.
In legal stuff, a boundary is often given by a
'property line', or similar two-dimensional idea. This line has no physical
reality: its location is given by metes and bounds, but that's not the line
itself. A property line may be marked, but the marks are not the line, even if
the marks are linear; they're just another representation, an informal one, of
the metes-and-bounds definition. The boundary is a notional surface, running
vertically from the center of the earth (or so) to the limits of the atmosphere
(or so), intersecting the surface of the earth (the air-ground interface!)
along the property line.
This boundary is a sufficient concept for two
pieces of software that don't interact, but it's not useful as the concept of an
interface.
My house is on a property with several boundaries,
distinguished by what property is on the other side of the boundary. The
northerly corner has a recorded easement for utilities: there is a
telephone-company distribution box and a power-company transformer there, that
also serve the properties abutting mine. The east and south sides abut city
property, street rights of way. Those boundaries are of a nature different from
the boundaries with the three abutting residential properties.
The
streetside boundaries have ordained easements to street users for vehicle entry
(driveway), and special easements for me onto the street right-of-way: I am
allowed to put my trash at curbside along that boundary — but nowhere else
— for street-side pickup. I am required to maintain the lawns on the city
property that abuts our mutual boundary, and to remove snow from the sidewalks
there. There are ordained easements for everyone to use the streets for
streetish purposes: as a street abutter, I have easements to violate the
boundary for those required purposes.
There are necessary easements for gas
and water services, not recorded nor ordained, but implied by the nature of my
interaction with the gas and water companies, and implied easements for
meter-readers and the like, too.
Two pieces of interacting software have
a boundary, defined by the extents of the software: it's a notional surface,
possibly closed (where the property boundaries are open at the top). In order
for them to interact, at least one must provide easements to the other, for the
purposes of the interaction. (I'll avoid mentioning memory or processor
hogging, where one can interact by denial of resources to the other.)
These
easements are characterized by the nature of and requirements for the
interaction. We call them APIs, when one is a service provider and the other is
an application program, using those services. These characteristics may (or, if
you consider Microsoft, might not) be documented: in any case, the metes and
bounds, the recording, the documentation is not the easement. When the
documentation says that a particular incantation is required to invoke the
easement (java.lang.String), it's giving an incantation that, by the merger
doctrine, is inseparable from the idea.
Sun defined the incantations with a
necessary SSO, such that the SSO is inseparable from the
idea.
---
--Bill. NAL: question the answers, especially mine. [ Reply to This | Parent | # ]
|
