Hi Danushka,
Yes, I agree that these would both be improvements - thanks! (Actually,
that's kind of the difference between a quick slideshow summary and real
API docs, which I want to use this as a basis for.)
Jonathan
Danushka Menikkumbura wrote:
Jonathan,
I just ran through the API and I really like the flow of it. It covers
almost all the things, I like to point out the following suggestions,
though.
1. The best format for an API doc would be to have the function
blueprint, then the default values and finally the possible values for
enums and stuff like that. If we take setDeliveryMode function on page
76 for an example, we first have the actual function blueprint with
data types and then have an example and after that possible values for
the delivery mode. (i.e. other than PERSISTENT, what else we can have
and probably the default mode).
2. I suggest you be bit more descriptive about certain things. For
and example, under SubscriptionManager on page 89, it is better if we
can note the difference between /cancel /and /stop /methods.
Danushka
