Re: I-D ACTION:draft-ietf-btns-c-api-00.txt
Nicolas Williams <Nicolas.Williams <at> sun.com>
2007-07-19 22:54:20 GMT
On Thu, Jul 19, 2007 at 03:21:10PM -0700, Caitlin Bestler wrote:
> > You are mis-understanding the requirements.
> > The requirements are there in order to free the API
> > developer to be able to do what make sense in a multitude of
> > environments. An object is said to be opaque to make sure
> > that the *APPLICATION* does not depend upon the ability to
> > look into the object in order to function.
> > An object is said to be non-copyable, in order that you do
> > not assume that you can copy it trivially by doing a structure copy.
> > In both cases, if your choose to implement the accessor
> > functions as #define macros, and the copy function as
> > *foostruct=*barstruct, that's just fine.
Well, I would hope not -- implementing accessor functions as macros
makes the structure of the object part of the ABI, even though not part
of the API. :)
> > However, in a Posix environment, I can not assume that
> Would you be ok with explicitly clarifying that the requirements
> described are only intended for the application layer code, and are
> not intended to constrain implementaion of the operating environment?
I think it should be quite clear already that "opaque" here means "with
respect to the application" since we're defining an API. (And
certainly when the language is compared with that of other Internet RFCs
that describe APIs.)