|
Authored by: Anonymous on Wednesday, April 25 2012 @ 11:10 AM EDT |
Ive watched as people try to describe an API.
We've had difficulty explaining it.
I thought, let's start again. From what we know.
Let's say I write lots of code, in several files. This code does things.
I write more code, with different functionality. I keep this body of code
separate
from the first.
Again and again, 37 times.
The CODE I write is mine. You cannot use it, its copyrighted.
This code is useless to anyone but myself, because no one knows HOW to use it.
I then write a description of what things those 37 bodies of code does. This
document is also copyrighted. Its a different copyright than I have on the
files in
the 37 other bodies of code.
Let's call those 37 bodies of code, packages.
Lets call the document that describes the functionality of those the API
specification.
The API specification is a 'contract' that fixes the functionality of the
packages.
I have said how it works, what the output is for a given input...
I know have a document that you can use to write your own programs that does
whatever it is you want, when you use MY packages.
I make my packages available for free on specific terms and conditions. You are
getting the compiled packages and API specifications. You aren't getting my
source.
You and everyone can write code knowing and relying on the 'contract'.
In time, I let you see the source for one of my packages. You see that I have
described what it does quite well, in the API specification, but I've coded it
poorly. You re-write the code, without changing the API specification for this
package.
You can do this for all of my packages. You can call yours harmony.
Your code is different than mine, with its own copyright.
The interfaces to both are the same. They need to be for interoperability.
Back in the day, I would have said that at a programmatic level, that even
though
I might have a copyright on a specific file that you used as the INTERFACE to
either of our packages, it was fair use for us both to use for
interoperability.
We could use header files describing the interfaces without using each others
implementations of those interfaces.
Requiring other users to re-write their code to use different interfaces to
access
our separately developed packages with essentially the same functionality would
be a colossal waste of time. All the advancements that have taken place over
the
years of development have come precisely because we built on a well defined set
of basic interfaces. Whole new bodies of code, (packages) have been developed
because each development group could rely on the basic packages and build on
it.
After years of such reliance, after years of promoting my specific API
specification, through books, standard bodies and years of software releases,
the
community has an expectation that those API specifications, those contracts,
will
continue.
All this seems compatible with what I know about copyrights. I own the
copyright to the source code I wrote in my packages, you own yours. The
SPECIFIC document that I wrote to describe the functionality of my packages, I
own. The INTERFACE itself, I thought in the past was not copyrightable, as it
was
an description of the copyrightable implementation of the code and required for
interoperability. Interoperability at one time was perceived as a 'good thing'
and
was allowed on grounds of fair use.
[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Wednesday, April 25 2012 @ 11:14 AM EDT |
Does baking a cake work for you?
- Specification - provide a specific
cake given a specific
type and quantity of ingredients. Here all possible
things
are described like the type of flours that can be used (in
the USA this
includes All-purpose, bread, cake, and self-
rising).
- Interface -
perhaps the actual ingredients and quality
of each ingredient like a cup of
flour
- Implementation - all the things that result in a cake.
Check for
the correct ingredients and associated quantities.
Steps to combine the
ingredients and actually cook the cake
- probably as defined in the
specification.
Notice that the API, probably the implementation aspect,
may
call other APIs like preheating the oven to some
temperature. Also there
could be multiple cake baking APIs
for different cakes as in the way APIs are
being described
in the case (as libraries).[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Wednesday, April 25 2012 @ 03:47 PM EDT |
It's a figment of your imagination.
There is the document that describes what is expected to happen in association
with 'a name', this is an API Specification.
there is some source code, that may (you hope, it may not, be warned) attempt to
describe in a programming language, that which is expected to happen as
described in the document.
That source code can be compiled to an object code representation of the source
code.
(these *two* things, are sometimes referred to as an "API
Implementation", while it is sort of true, it does not distinguish and it
misstates what those two things are)
Subsequent use of the name in conjunction with other tools, to reconcile the
name with it's offset in the object code can cause the object code at the offset
to be executed on request
I don't think that uses any terms that are difficult to understand
There may be extra hidden wizardry in a bytecode (e.g.JVM) type environment, it
does not change anything, for all the magic, the name, gets translated to an
offset which is used as a pointer from which to start executing object code.
That is what an API is. Magic.[ Reply to This | Parent | # ]
|
|
|
|
|