[haiku-depot-web] Re: API getPkg()

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-depot-web@xxxxxxxxxxxxx
  • Date: Mon, 07 Apr 2014 17:09:00 +0200

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

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,

Other related posts: