To provide API for third party, which is best way? 
Author Message
 To provide API for third party, which is best way?

I have to provide an API for a third party, which is best way of
giving an API?. Is it better to give the source code or just make an
library and give it to them, If I give the library Is it OK, Is there
any problems might come?. Is there any other way is there?.
Appreciated and thanks.
--



Sat, 15 Oct 2005 23:45:52 GMT  
 To provide API for third party, which is best way?

Quote:
>I have to provide an API for a third party, which is best way of
>giving an API?. Is it better to give the source code or just make an
>library and give it to them, If I give the library Is it OK, Is there
>any problems might come?. Is there any other way is there?.

API standing for Application Programming Interface, the usual way of
providing it is as a well documented library.  Without any additional
information it's hard to say whether the library is best provided as a
binary, as source code or as both.

Dan
--
Dan Pop
DESY Zeuthen, RZ group

--



Sun, 16 Oct 2005 07:20:21 GMT  
 To provide API for third party, which is best way?

Quote:

> I have to provide an API for a third party, which is best way of
> giving an API?. Is it better to give the source code or just make an
> library and give it to them, If I give the library Is it OK, Is there
> any problems might come?. Is there any other way is there?.

You need to specify more carefully just what it is that the third
party expects from this transaction.  An "API" is just an
interface, usually thought of as a specification for functions
and objects with external linkage, declared in an associated
header file.  To *use* the API in an application, of course one
needs a library to provide an implementation of the interface.
If you do not own the rights to redistribute the library (or the
header, or the specification), then you need to obtain permission
from the rights holder.
--



Sun, 16 Oct 2005 07:20:52 GMT  
 To provide API for third party, which is best way?
Santa> I have to provide an API for a third party, which is best way of
Santa> giving an API?.

Is this a technical question or a legal question?  To whom will you
give this API, a co-worker, a friend, a business partner?  If this is
a legal question, I can not help you.

Santa> Is it better to give the source code or just make an
Santa> library and give it to them, If I give the library Is it OK, Is there
Santa> any problems might come?.

I am sure it is better for the receiver to get the source code,
because then they know exactly what you did.  They could then modify
the code to suit their and perhaps your needs.  

If this is your work product then you may want to talk with a Lawyer.
If this is corporate code, then you likely will need to talk with
somebody in your corporation before sending ANYTHING outside.

A library with nicely documented header files is a fine way to
distribute code.  Good, separate, documentation in addition to the
library and documented header files would be even better.  :-)

--
-MM
I rarely read email from this address          /"\
because of spam.                               \ /     ASCII Ribbon Campaign
I MAY see it if you put #NOTSPAM#               X      Against HTML Mail
in the subject line.                           / \
--



Sun, 16 Oct 2005 07:21:07 GMT  
 To provide API for third party, which is best way?

Quote:
> I have to provide an API for a third party, which is best way of
> giving an API?. Is it better to give the source code or just make an
> library and give it to them, If I give the library Is it OK, Is there
> any problems might come?. Is there any other way is there?.
> Appreciated and thanks.

An API is just an Application Programming Interface, which basically
means a description of how a programmer will use a set of functions
(i.e. what functions to call, what arguments to give them, what behaviour
to expect, what assumptions have to be respected).

At a minimum, assuming it's written in C, you need to provide a set of
header files, the library itself, and documentation of how to use it
(eg what headers need to be #included and when, how to link).

The main possible problem with not providing source code is if the
"third party" (presumably a programmer) wishes to use a different
development environment than you have, and his can't accept the
library files you provide.    That may mean you need to provide
multiple compiled libraries, and instuctions for using them on each
target operating system or with each compiler/linker/etc.

Providing source code allows the customer to do a port if they
need to.  It also allows them to modify the library if they see fit.
That is a double edged sword:  it allows them to fix bugs and
send them back to you.   But if they give a modified library to someone
else, you may get spurious bug reports caused by code changes
you know nothing about.

There are also all sorts of non-technical issues you will need to consider.
Some customers won't accept a libary without source code.
Whether you provide source code or not, you may need to worry
about things like licensing or copyright.   There's also an issue of
warranty (eg what happens if your system does unintended damage
to the customer).  For those sorts of things, you need to talk with
non-technical specialists (eg legal specialists).
--



Tue, 18 Oct 2005 15:27:09 GMT  
 To provide API for third party, which is best way?

Quote:

> I have to provide an API for a third party, which is best way of
> giving an API?

There is no single "best" way of doing that.  Different contexts, in
terms of legal, organizational and technical constraints, call for
different methods.

An API is usually thought of as a rather abstract object.  You can
define an API without having either the server or any client actually
existing in the form of actual code.

The minimal way of defining an API, in the context this newsgroup is
about, would be to provide two things:

1) a code library for the target platform.  Whether in source or binary
   form is mainly a legal and organizational question, thus off-topic
   here.

2) a heavily commented header file.

Users of your API can then #include that header in their code, call
the API's functions, and link their programs against the library.
Reading the comments in the header file, they can learn how to use it.

Some would insist that the header file should be lean-and-mean, and
the documentation be kept in a separate file instead.  One more easily
hyperlinked, printed and otherwise enhanced, say.  You choose.

Others would insist you must provide source code, at least on a basis
of "should I, the provider of this API, no longer be available to
re-compile the library for my customers, it's guaranteed that the
source code can be obtained from an escrow service".  As I said, this
drifts quickly into the legalese department.
--

Even if all the snow were burnt, ashes would remain.
--



Tue, 18 Oct 2005 15:27:39 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Third party component set opinions

2. How to link third party .LIB files

3. How to link third party .LIB files

4. Importing third party interfaces that have the same name into an IDL file

5. First-chance exception in third-party DLL

6. Third party DCOM referrals?

7. ?Seeking Recommendations re: Third Party Database Engines

8. debugging 'third party' *.exe

9. Looking for third party tool

10. First-chance exception in third-party DLL

11. How do I Link with a third party static C library

12. Importing some functions from a third-party DLL

 

 
Powered by phpBB® Forum Software