New USB-Statistics API

[Julian Scheel <julian@jusst.de>]

Hello together,

after the last thread which asked about signal statistics details 
degenerated into a discussion about the technical possibilites for 
implementing an entirely new API, which lead to nothing so far, I wanted 
to open a new thread to bring this forward. Maybe some more people can 
give their votes for the different options

Actually Manu did propose a new API for fetching enhanced statistics. It 
uses new IOCTL to directly fetch the statistical data in one go from the 
frontend. This propose was so far rejected by Mauro who wants to use the 
S2API get/set calls instead.

Now to give everyone a quick overview about the advantages and 
disadvantages of both approaches I will try to summarize it up:

1st approach: Introduce new IOCTL

Pros:
- Allows a quick fetch of the entire dataset, which ensures that:
  1. all values are fetched in one go (as long as possible) from the 
frontend, so that they can be treated as one united and be valued in 
conjunction
  2. the requested values arrive the caller in an almost constant 
timeframe, as the ioctl is directly executed by the driver
- It does not interfere with the existing statistics API, which has to 
be kept alive as it is in use for a long time already. (unifying it's 
data is not the approach of this new API)

Cons:
- Forces the application developers to interact with two APIs. The S2API 
for tuning on the one hand and the Statistics API for reading signal 
values on the other hand.

2nd approach: Set up S2API calls for reading statistics

Pros:
- Continous unification of the linuxtv API, allowing all calls to be 
made through one API. -> easy for application developers

Cons:
- Due to the key/value pairs used for S2API getters the statistical 
values can't be read as a unique block, so we loose the guarantee, that 
all of the values can be treatend as one unit expressing the signals 
state at a concrete time.
- Due to the general architecture of the S2API the delay between 
requesting and receiving the actual data could become too big to allow 
realtime interpretation of the data (as it is needed for applications 
like satellite finders, etc.)

I hope that this summary is technically correct in all points, if not 
I'd be thankful for objective corrections. I am not going to articulate 
my personal opinion in this mail, but I will do it in another mail in 
reply to this one, so that this mail can be seen as a neutral summary of 
the current situation.

So now it's everyones turn to think about the options and give an 
opinion. In the end I am quite sure that all of us would have great 
benefits of an improved statistics API.

Cheers,
Julian