Closed mberg closed 11 years ago
Will we be allowed to add our own properties here? I already see situations where we are duplicating data in the properties field..
I think that in 1.1 the meta field would be useful as total_count can be used to drive progress bars for asynchronous fetching of data (i.e. download results in a different thread, and drive a progress bar on the UI thread).
I would probably not make it optional (or would make at least limit, offset and count mandatory) as the more optionality you provide the harder it is for clients to write software that is generic (i.e. the client doesn't have to "discover" if a facility registy supports option X. Or if it supports option X properly).
Can we look into including this in 1.0? Since we now actually supports paging (with a default limit!) it will be very useful to have this kind of meta-data.
I'd like to have next, previous... if we are doing that block in v1.0 Its really useful for the client that are going to use the service. So they can be dumber!!
Also, please rename total_count
to total
While I think its not ideal to have this block I'm not opposing. We need to make sure the names of the fields are coherent across the specs, queries etc.
Discussed 7 March. Agree with caveat to change to totalCount
Meta Summary Data
Results return a meta block of summary resultset data to make client application development easier. This is an optional feature to the core API.