Change many SDK API signatures to be consistent
-----------------------------------------------
Key: TS-590
URL: https://issues.apache.org/jira/browse/TS-590
Project: Traffic Server
Issue Type: Improvement
Components: TSAPI
Reporter: Leif Hedstrom
Fix For: 2.1.5
As has been discussed on the dev@ mailing list, we should clean up some of our
APIs. I'm filing this bug here to track the discussion that has been had so far.
The general consensus is that we'll stick to two types of signatures. The first
one will presumably be the common one:
1) For any API that can fail (e.g. due to bad input, wrong types, or errors
internally etc.), we'll stick to an interface of the form
TSReturnCode TSSomeAPI(int in_param1, char *n_param2, int *out_param1,
char **out_param2);
we might want to consider adding some new error types to TSReturnCode as well,
right now it's only error or success. One addition could be BAD_INPUT for
example. But, we'll consistently use TSReturnCode only for indicating some sort
of failures (i.e. no overloading of NULL pointers, -1, 0 etc. for a returned
POD to mean failure).
2) For APIs that can not fail (quoting amc: "I promise to return something
useful, or I will not return at all"), we allow the API to return a POD type.
For Get() and Set() methods, we indicate this promise by dropping the Get() or
Set() part of the name For example, TSMimeHdrLengthGet() becomes:
int TSMimeHdrLength(TSMBuffer bufp, TSMLoc obj)
This API can currently not fail in a release build, in debug builds, we should
change such non-failing APIs to use ink_assert() on the sanity checks. The
example above is particularly "bad" IMO, since it returns a length of -1 to
mean that the assert failed. In the implementation of this new version of the
API, we'd have asserts like
int
TSMimeHdrLengthGet(TSMBuffer bufp, TSMLoc obj)
{
ink_assert(sdk_sanity_check_mbuffer(bufp) == TS_SUCCESS);
ink_assert(sdk_sanity_check_mime_hdr_handle(obj) == TS_SUCCESS);
...
We should make sure that we "group" similar APIs together properly, i.e. it
makes no sense for dealing with (e.g.) TSMimeHdrFieldGet() as a can-fail API,
and TSMimeHdrFieldFind() as one that can not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.