- User Since
- Sep 7 2015, 3:43 PM (252 w, 5 d)
Mon, Jul 6
Fri, Jul 3
Thu, Jul 2
@civodul I wanted to raise the topic of storing container metadata (in the style of what tools like pristine-tar do) here too, so thanks for giving me the chance :-)
I agree it might be a technical solution, *but*, I'm not sure I see the point.
Didn't you agree that having a "lookup service" from tarball/container checksums to SWHIDs (the Software Heritage identifiers, that can then be used to lookup stuff in the archive) would be enough to satisfy distro needs?
If yes, then "archiving container metadata" could be replaced by simply having a way to add entries to the lookup table. And allowing distros to do so is option that we can explore. (Once the service exists, of course.)
Tue, Jun 30
I suspect when this task was initially submitted we didn't have yet SWHID with qualifiers :)
From the point of view of the APIv2, given v1 was using only hashes, for feature parity we should indeed only need SWHID without qualifiers, i.e., "core" SWHIDs. (I'm gonna edit the task description to reflect that.) Thanks for noticing this!
Sat, Jun 27
Wed, Jun 24
Mon, Jun 22
Fri, Jun 19
as a related data point, the current graph export code applies the following heuristic to decide which outbound edges from snapshot nodes to emit:
- keep branch names starting with refs/heads/
- keep branch names starting with refs/tags/
- drop everything else
Wed, Jun 17
thumbs up for a dedicated permission for API throttling, thanks !
@lewo it's used in our DB but also exposed in the swh-web UI in search results (and in the future it is going to be also be a field for user searches, so that you can search, e.g., "emacs" only in the list of packages archived from a given origin type).
Tue, Jun 16
Sun, Jun 14
Making explicit a direct answer to one of @lewo's question (hinted at by both @olasd and @rdicosmo): no, we do not want a new type of SWHID (swh:1:tar:...) for source code containers, which from our point of view are ephemeral.
Yeah, for having played with it quite a bit in recent times, the current state of timestamp offsets isn't great. I'm fine with the idea of switching them to bytestrings as proposed.
Fri, Jun 12
Another option is to simply drop this method from the public Web API, and keep the revision graph visit logic only in swh-web (the UI). If users want to do a full visit of the revision graph they can use /revision and implement the visit policy they want. (I've suggested this design consideration for API v2 in T1805.)
Jun 9 2020
Jun 8 2020
Jun 5 2020
FWIW we have discussed already a related aspect in T1805 ("Use SWH PIDs whenever possible"). There it was only for the Web API, but it seems wise to do the same for /browse/ URLs too.
The webapp then enables to browse a content from each computed checksum using the following URL: /browse/content/(algo):(hash)/
Jun 4 2020
Jun 3 2020
May 30 2020
May 28 2020
May 27 2020
duplicate of T2420
May 26 2020
May 24 2020
May 22 2020
May 20 2020
May 19 2020
May 18 2020
May 16 2020
May 14 2020
Question: can we support both context-full and context-less metadata for arbitrary artifacts?
May 13 2020
May 12 2020
May 11 2020
May 10 2020
May 7 2020
Given Wikidata software properties already contains "source code repository" URLs, shouldn't we work on our side to make sure those URLs resolve to corresponding origin URLs, rather than adding yet another property (very similar to "source code repository") on their side?