Add support for accessing books using a metadata-based ID

[vighnesh-sawant]

Fixes #1057

Changes:

• Added a filter to the catalog endpoint catalog/v2/entries?id="id", allows to filter based on uuid
• On the viewer endpoint added a check if supplied arg looks like a uuid using regex and then fetched the bookName from the catalog endpoint and kept the rest same after that.
• handle_location_hash_change()made async (I dont think it will but comments will be helpful)
• On the /content endpoint, same check as viewer endpoint to see if it looks like a uuid, but this endpoint was handled in the server so just used a function to convert id to name and name to id.

Please do tell if i missed something! I would love to rectify it.

Also i just wanted to ask if there is a reason why /viewer is handled in client-side js while /content on server-side? I am just a little curious.

[vighnesh-sawant]

@kelson42 Hey can you please have a look at this I forgot to tag before so am tagging now.

[vighnesh-sawant]

I think this is ready for review.

[kelson42]

@vighnesh-sawant Thank you for your PR, I have finally a bit of time to look at it.

[rgaudin]

Haven't looked at it carefully but it looks like it supports the UUID as input but doesn't redirect so UUID request will look like UUID in the address bar of browsers. That's not what's on the ticket I believe.

[kelson42]

@rgaudin Although I perfectly agree that we need (1) a way to access a ZIM file from an identifier which is not versatile like the filename (2) that the uuid is (obviously) a really good unique identifier; I kind of feel that we might don't have qualified fully this issue #1057.

My points which are unclear are:

• Do we have to use the UUID to address a specific ZIM file in quite clear way? Would having something using the "name" metadata not as good or good enough?
• If we use the uuid, do we have to make the URL user-friendly? I mean we have the ZIM name "metadata" for that?... and therefore the "redirection" part of the feature request might not be the best thing to do?

Maybe we should discuss briefly these points first so we can give a coherent feedback to @vighnesh-sawant as he has already done quite a bit of work.

[vighnesh-sawant]

The PR implements the redirect feature also, accessing by uuid redirects to the current format. I'll wait for feedback and change the code as necessary!

[rgaudin]

• Do we have to use the UUID to address a specific ZIM file in quite clear way? Would having something using the "name" metadata not as good or good enough?

The Name metadata as per the spec is free text set by ZIM Creator. There are thus chances to have duplicates in a local catalog. We try to create openZIM ones with unique names but as soon as there are other ZIMs, chances of duplicates rise. So using this, kiwix-serve would still need to maintain a duplicate circumvention mechanism and thus we won't be able to predict working links just from metadata.

• If we use the uuid, do we have to make the URL user-friendly? I mean we have the ZIM name "metadata" for that?... and therefore the "redirection" part of the feature request might not be the best thing to do?

We've been supporting and advocating user-friendly URLs everywhere for years, for good reasons. I believe it's not a big drawback to have a redirect on initial request.

---

@vighnesh-sawant sorry for assuming it was not using a redirect ; I was mislead by briefly looking at code and seeing xapian stuff. Indeed the PR is exactly what was requested and works like a charm.

The only missing part is checking all endpoints where a similar treatment is required. For instance, it doesn't work on /raw (you didn't change handle_raw). Please check them all as I think we don't want different behaviors. /suggest, /search, /random, /catalog to name a few.

[benoit74]

I also don't see why kiwix-serve should prevent to serve multiple versions of the same ZIM Name (which would happen if we use ZIM Name as unique identifier instead of UUID).

This is not our usage as for now, but could be for some of our users, and this could even be handy for us in dev (https://dev.library.kiwix.org/) where one might want to be able to see all ZIMs we have on the filesystem to easily compare them.

The redirect from UUID to filename seems kinda mandatory to help users from my perspective.

[veloman-yunkan]

The only missing part is checking all endpoints where a similar treatment is required. For instance, it doesn't work on /raw (you didn't change handle_raw). Please check them all as I think we don't want different behaviors. /suggest, /search, /random, /catalog to name a few.

@rgaudin Your original request was to only go after /viewer#{bookId} and /content/{bookId}. I wouldn't point to it, had you not used the word "ideally" in your description of the desired solution. Now I don't understand why you want internal endpoints to support the UUID-based URL scheme as well.

I would advise that the work on this PR is suspended until we sort out a number of design decisions. The first question that I want to be answered is asked in the ticket.

[rgaudin]

@veloman-yunkan those are the ones I have current need for. I just think (now) that it would make sense to apply the same thing to other bookName-based endpoints, so that the API is more homogeneous.