On Sat, Nov 30, 2002, Nate Bargmann wrote:
> As I've worked on the backend library for the FT-920 a number of the
> warts and quirks of the radio are exposed through the frontend library
> to the application. Really, I think this is incorrect as Hamlib should
> hide these things from the application.
Like what? Can you give some example?
> So, what I would like to see in the API documentation is a description
> of the expected behavior of the function at hand. While this is often
> obvious, some things are more subtle and I would like a more defined
> target to work toward.
I'd love such documentation exists. Unfortunately, the only thing I can
do, is to reply the best I could to question when they are asked.
Writing specification, as valuable as it can be, is time consuming when
done alone. Any volunteer?
> Thus I think a firm definition of the virtual radio Hamlib presents to
> the application would be a big help to authors on each side of the
> frontend.
Sure a written definition is much needed!
So far, it has not been done because:
- lack of time and lust
- developers tend to prefer to develop rather than write documentation,
especially when they do this as a hobby
- the design of the API is not complete yet. It has to cover all the rig
combinations over there. BTW I'm still not satisfied with the vfo_t.
It may look silly to document something that's going to change in
the near future, waste of energy.
So let's be pragmatic. Everyone is encouraged to submit comments on
existing flaws,limitations,.., and how they see the API should be designed,
point by point.
The resulting API documentation is to be put in the doxygen comments, and
also in the docbook manual.
Stephane
|
