|
Authored by: Anonymous on Thursday, May 24 2012 @ 01:55 PM EDT |
Also consider the large number of the SPI APIs shipped with Java. It is the
responsibility of vendors to provide implementation while adhering to the API.
Eg: JDBC, JCA, JNDI. Any vendor's implementations <b>must</b>
support the exact same API.[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Thursday, May 24 2012 @ 04:35 PM EDT |
Do APIs in general even HAVE an SSO. I mean an SSO distinct from the instruction
set itself which is unprotectable.
Sequence? An API is an instruction set. It is used. It isn't read in a linear
fashion. Where does one observe this sequence?
Structure? Java is a little unusual in having a hierarchical naming convention.
I suppose you could call this a structure, although I think it is more of an
idea than a structure.
Organisation? See structure.
Bear in mind that this will be a precedent setting decision. It is going to make
law. Some thought needs to be given as to making that law applicable not just to
the instant case. Java is unusual in that the API instructions are named
hierarchically. Most APIs don't do this. If SSO equates to this hierarchy you
are talking about something that most APIs lack. Protecting APIs based on an
argument about their SSO is going to lead to considerable legal angst as people
argue about something which is very ill defined and poorly identifiable in most
APIs.
Furthermore I cannot see how you can easily separate the hierarchy itself from,
on the one hand, the idea of having hierarchical names, which is an
unprotectable idea; and on the other hand from the names themselves which are
unprotectable functional elements (and words in the language of Java to boot). [ Reply to This | Parent | # ]
|
|
|
|
|