decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Blueprint | 687 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Blueprint
Authored by: Anonymous on Friday, April 27 2012 @ 07:31 PM EDT
I tend to disagree, in that I see the architectural analogy going more like
this:

Library / Package = The house
API = That which allows ingress/egress (doors, windows, pipes, etc.)
Implementation (source) = Blueprints
Implementation (compiled) = Physical building
Compiler / Linker = Contractors / construction crew
Compile/Link process = Construction process
QA testing = Inspection

One could argue that the blueprints contain, in part, the API specification (not
the API itself) but they clearly contain much more in my opinion. Detailing not
just API but also implementation details. Blueprints just seem far too detailed
to me to just be API specs (and are definitely not the API itself).

Then again, I could be wrong. Again.

[ Reply to This | Parent | # ]

Blueprint
Authored by: tknarr on Friday, April 27 2012 @ 07:51 PM EDT

I don't know, it sounds like a good metaphor to me. If you have a house built, and I have a house built from the same blueprint, does that give you ownership of my house?

You might have a case against the architect for reusing the blueprints for your house without permission. You might have a trademark or similar case if I use unique aspects of the design of your house that're protected by law. But you don't get title to my house just because it followed the same floorplan as yours did.

[ Reply to This | Parent | # ]

Blueprint
Authored by: Anonymous on Friday, April 27 2012 @ 07:53 PM EDT
Unfortunately those not involved in construction misunderstand what
"blueprints", or more accuratly "construction drawings"
are.

I suggest a more correct word for the meaning wanted here is
"template". You can start with an existing API implementation (code)
or an outline API implementation, and use it as a "template" to
develop a new different implementation in the same medium. The points are the
new version is *different*, ie: not just a copy of the template, and it is *in
the same medium*, ie: also as as source code.

With respect to "blueprints", what is produced is *identical* but *in
a different medium*. If a builder properly follows house "blueprints"
the resulting building is identical to the "blueprints", ie same
layout, same sizes and dimensions, same materials as stated on the
"blueprints", same sinks as noted on the "blueprints",
possibly even same same paint colors. If properly constructed the constructed
house will be *identical* to that shown on the "blueprints". On the
other hand it is *in a different medium*, ie: it is in 3 dimensions and made of
concrete, wood, wallboard, glass etc. while the "blueprints" are 2
dimensional ink on paper.

The "blueprint" analogy is completely incorrect.

[ Reply to This | Parent | # ]

The Walking Tour
Authored by: BitOBear on Friday, April 27 2012 @ 08:07 PM EDT
I have, elsewhere, said that in this stack of building-and-blueprint analogy the
APi is the walking tour as you would present it (say over the phone) to a blind
person who was going to house sit for you.

There are things you would mark out specially, and things that go with barely a
nod, and things that the blind person would probably change if they were going
to -own- the property but which for now they must live with or work around.

Instances:

The main hall is straight in front of the door, but at the far side of the
foyer. On the right as you enter, the large space is the living room. The
bathroom is at the far end of the hall. There is a touch-screen thermostat right
were the main hall leaves but you probably will need a helper to mess with that.
and so on.

Now if the walking tour covered every single room "well enough" and
the blind guy decided he really liked the house. He could give the same exact
"walking tour" to an architect and say I want a house just like that.

Now the first house might be brick and on a large property, and the blind guy
might have a smaller parcel of land in a hotter climate so the rooms might be
smaller and the house would be wood.

The blind guy might also decide that the touch-screen thermostat would be better
replaced with a nice tactile knob-style.

Is it the same house? Not at all. Does it have a compatible floor plan? Yes.

When one implements an API one implements compatibility, congruence if you will,
but an API isn't blueprints because an API doesn't tell you -how- something is
built at that level of detail. Blueprints include materials and stresses and
loadings and plumbing to the street. All these things vary from lot to lot in
real life and always vary implementation to implementation in magical world of
software.

[ Reply to This | Parent | # ]

Sadly incorrect and highly misleading. Not a Blueprint
Authored by: celtic_hackr on Friday, April 27 2012 @ 10:21 PM EDT
Having worked with blueprints, I can tell you the analogy is completely wrong.

Blueprint = API + sourcecode + ball of wax.

A blue print tells you exactly and precisely every little step to duplicate.
It's the whole shebang.

No, what you're thinking of is the "conceptual drawing". That shows
you an artist's rendition of the shape and size of the house and may or may not
give you the sizes of the rooms and number of rooms, etc. It doesn't tell you
how many outlets to use, the wire sizes, the size of the air-conditioner, the
supporting beam structures and locations, the materials, and a whole book's
worth of other engineering requirements and specifications.

To see the difference, try taking a conceptual drawing to your local
building/planning/zoning office and try to get a building permit. Then try
taking a simple CAD drawing with more detail, and then try it with actual
blue-prints which will cost you a few thousand dollars to get. Unless you live
deep in the Appalachias, I doubt you'll meet with much success.

Tell me which one(s) worked.

[ Reply to This | Parent | # ]

An API is the symbols on a blueprint, not the design it depicts
Authored by: Anonymous on Saturday, April 28 2012 @ 11:15 AM EDT
In the Blueprint analogy, an API seems to me to be much closer to the drafting
conventions and symbols that are employed in the drawing, than to the design it
depicts.

An architectural draftsman employs a standard set of symbols that depict the
elements of the design: walls, doors, windows, plumbing, structural hardware,
and the like. The symbols comprise a common "language" that allows the
drawings to be "read" by anyone who has learned it.

When I designed my home, I hired someone who spoke the language to make the
drawings that accompanied my application for a building permit. A drawing that
used symbols that I made up myself would not have been accepted.

So by analogy, an API defines a set of symbolic elements that can be used to
design the architecture of a program; it is not itself a design. Nor does it
tell one how to make a design, but rather is a set of components that one
skilled in the art can use to do so.

[ Reply to This | Parent | # ]

Blueprint
Authored by: BJ on Saturday, April 28 2012 @ 02:10 PM EDT
Objection: Argumentative!

bjd

[ Reply to This | Parent | # ]

  • Blueprint - Authored by: PJ on Saturday, April 28 2012 @ 06:03 PM EDT
Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )