Looking for some general approaches to problems I'm having writing an elisp library

[Jeremiah Dodds <jeremiah.dodds@gmail.com>]

I'm writing an elisp library that's meant to be used by other elisp
code. It provides communication with a REST API, the goal is to allow
other packages to talk to the API via relevantly-named function calls,
I'm writing one client package in tandem with the library.

The API requires an authorization token to be passed in order to allow
read access to "private" things, or write access to anything. 

I could use a single auth token for the library itself, but that seems
like a bad idea -- it's more of a middleman than the application
performing operations.

The obvious solution is to store an auth token per client-application,
the issue I'm having is how this should be exposed. I'd like to avoid
forcing client code to be redundant.

Approaches I've thought up:

+ require client code to pass it's name on each request.
+ when a client application becomes known to the library, define
  wrappers for the various api functions. 

I feel like the "right" way to go about this is something like the
second approach, I know this is the type of thing that lisps are fine at
handling, but I'm not familiar enough with elisp to know but what the
appropriate way to handle this is.

Does anyone who breathes elisp have a "best practice" for something like
the following simplified scenario:

Client packages A and B both use library C. C provides a function,
'c-get-some-data' that both A and B would like to
call. 'c-get-some-data' needs to be able to use a value that is specific
to the package calling it, that value is unlikely to change once
set.

How can I make sure that if A and B are both making calls to
'c-get-some-data' that the correct value is being used without resorting
to making the call look like (c-get-some-data "A") or similar? Or does
it sound like I'm thinking about the problem incorrectly?


-- 
Jeremiah Dodds

blog       : http://jdodds.github.com
github     : https://github.com/jdodds
freenode   : exhortatory
twitter    : kaens