@anlambert This ticket might have some performance implications.
for eg: in the first case, to redirect /browse/origin/directory/?origin_url=<> to the root directory, we have to query the archive first. The obvious way would be to call the get_snapshot_context function.
https://forge.softwareheritage.org/source/swh-web/browse/master/swh/web/browse/snapshot_context.py$395

The issue is, the redirected url (/browse/directory/<sha1>?origin_url=<>) will call the same function (get_snapshot_context) again. This is true for all the urls.
Do you see some other efficient alternative to fix this ticket?

The issue is, the redirected url (/browse/directory/<sha1>?origin_url=<>) will call the same function (get_snapshot_context) again. This is true for all the urls.
Do you see some other efficient alternative to fix this ticket?

@jayeshv, all costly storage requests result (getting origin visits, snapshot content and size) performed by the get_snapshot_context
function are cached at the django level so no need to worry about performance here as it has already been handled.

In T3608#71673, @anlambert wrote:

The issue is, the redirected url (/browse/directory/<sha1>?origin_url=<>) will call the same function (get_snapshot_context) again. This is true for all the urls.
Do you see some other efficient alternative to fix this ticket?

@jayeshv, all costly storage requests result (getting origin visits, snapshot content and size) performed by the get_snapshot_context
function are cached at the django level so no need to worry about performance here as it has already been handled.

Ok. Thanks

@anlambert do you think we can deprecate following routes as well? I think they can be redirected to the corresponding swh/web/browse/views/<object_type>.py routes.

• /snapshot/(?P<snapshot_id>[0-9a-f]+)/content/
• /snapshot/(?P<snapshot_id>[0-9a-f]+)/directory/(?P<path>.+)
• / snapshot/(?P<snapshot_id>[0-9a-f]+)/directory/
• `/snapshot/(?P<snapshot_id>[0-9a-f]+)/content/(?P<path>.+)/'

we can delete a lot of code from snapshot_context.py module then

Just to be clear, you're looking to keep these URL working, but turn them into redirects over to swhid-centric URLs with context parameters (and drop the original view code from these URLs), correct?

I'm asking this because using predictable origin-centric URLs is generally much more user friendly than having to use multiple APIs to look up the SWHID of a given object before being able to construct the URL, and one would have to always to dynamic API calls to generate the URL for browsing the "latest archival" of a given origin.

For instance, the "archived origin" SWH badge https://www.softwareheritage.org/2020/01/13/the-swh-badges-are-here/ uses an origin-centric URL.

In T3608#71802, @olasd wrote:

Just to be clear, you're looking to keep these URL working, but turn them into redirects over to swhid-centric URLs with context parameters (and drop the original view code from these URLs), correct?

@olasd Correct, We are just doing a permanent redirect. In fact, we will run the same code twice because of this redirect (most notably get_snapshot_context function). @anlambert told it is fine as we are caching that.

I'm trying to reduce complexity here by deleting a lot of code that I hope is not used after this redirection.

In T3608#71803, @olasd wrote:

I'm asking this because using predictable origin-centric URLs is generally much more user friendly than having to use multiple APIs to look up the SWHID of a given object before being able to construct the URL, and one would have to always to dynamic API calls to generate the URL for browsing the "latest archival" of a given origin.

For instance, the "archived origin" SWH badge https://www.softwareheritage.org/2020/01/13/the-swh-badges-are-here/ uses an origin-centric URL.

@olasd If you want a sneak peek, here is a wip diff https://forge.softwareheritage.org/D6430
Ideally, no existing route will fail because of this fix.

Awesome, thanks for confirming this!

Just to be clear, you're looking to keep these URL working, but turn them into redirects over to swhid-centric URLs with context parameters (and drop the original view code from these URLs), correct?

Yes the idea is to reorganize browse URLs as most of them are now redundant and remove kind of duplicated code in views implementation.

I'm asking this because using predictable origin-centric URLs is generally much more user friendly than having to use multiple APIs to look up the SWHID of a given object before being able to construct the URL, and one would have to always to dynamic API calls to generate the URL for browsing the "latest archival" of a given origin.

It will still be possible to use that kind of URLs, for instance /browse/directory?origin_url=<origin_url> will redirect to
/browse/directory/<root_sha1_git>?origin_url=<origin_url>&snapshot=<last_snapshot>
and will be equivalent to /browse/origin/directory?origin_url=<origin_url>

For instance, the "archived origin" SWH badge https://www.softwareheritage.org/2020/01/13/the-swh-badges-are-here/ uses an origin-centric URL.

Yes because it makes sense in that case.

In T3608#71800, @jayeshv wrote:

@anlambert do you think we can deprecate following routes as well? I think they can be redirected to the corresponding swh/web/browse/views/<object_type>.py routes.

• /snapshot/(?P<snapshot_id>[0-9a-f]+)/content/
• /snapshot/(?P<snapshot_id>[0-9a-f]+)/directory/(?P<path>.+)
• / snapshot/(?P<snapshot_id>[0-9a-f]+)/directory/
• `/snapshot/(?P<snapshot_id>[0-9a-f]+)/content/(?P<path>.+)/'

we can delete a lot of code from snapshot_context.py module then

Yes we can, the snapshot should be provided as query parameter in other views in that case.

Yes we can, the snapshot should be provided as query parameter in other views in that case.

Thanks. Then we can delete most of the code in https://forge.softwareheritage.org/source/swh-web/browse/master/swh/web/browse/snapshot_context.py

Testing will be a bit tricky, I will try to add some generic cypress test.

In T3608#71812, @jayeshv wrote:

Yes we can, the snapshot should be provided as query parameter in other views in that case.

Thanks. Then we can delete most of the code in https://forge.softwareheritage.org/source/swh-web/browse/master/swh/web/browse/snapshot_context.py

Testing will be a bit tricky, I will try to add some generic cypress test.

Yes, that's the idea, removing duplicated code.

For the tests, you should simply test redirections work as expected and replace the origin centric URLs by their SWHID counterparts in the tests code I think