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