Am 07.04.2014 15:14, schrieb Ingo Weinhold:
On 04/07/2014 01:37 PM, Andrew Lindesay wrote:
I have not tackled user-ratings just yet. I could perhaps bring in
screenshots and other detail into the "getPkg" method as _optional_
return data. It is a bit of balancing act of putting "too much"
material into one API call when the client might not need it for its
purpose. At the present time there is the opportunity to get this
material in the "getPkgScreenshots()" method; given that presumably an
HTTP socket is likely to remain open, is there any problem making
further invocations to get further (finer) detail?
Indeed, it's a balancing act between amount of (possibly not needed)
data and the number of requests to get the needed data. There seem to be
two strategies for a pleasant user experience: 1. Analyze the API usage
pattern of HaikuDepot and tailor the API for that purpose or 2. provide
very generic calls where the requests allow selecting from all the data
that can be provided. The latter may not be particularly elegant, but
it's most flexible.
I haven't looked whether the current API provides those yet, but in any
event, I think we'll benefit a lot from bulk calls that can provide
information on many/all packages at once. E.g. retrieving all
information displayed in HaikuDepot's package list with a single call
(or a few calls) will be much quicker than having to perform a call per
package.
Indeed. The API could be that the client specifies the package entries
and the type of information it wants in the response. This would reduce
the number of API methods and make the format of both the request and
the response dynamic, but I think it's still easy to form valid requests
and build a dynamic response on the server.
This approach also makes it easier to prioritize which packages to get
information for. During startup, HaikuDepot may realize that it has
information for certain packages in the cache, and no information for
other packages at all (these may be new packages). It could then
populate the information for the cached packages first, send a request
to the server for the new packages only, then a second request for the
cached packages, to update any outdated information.
I think this doesn't only work around performance problems in the
networking kit (which should be fixed regardless), but it would speed
things up even if those problems didn't exist, since it results in a lot
less forth and back between the client and server. It should also reduce
load on the server for the same reasons.
Best regards,
-Stephan
