- User Since
- Sep 7 2015, 3:43 PM (295 w, 4 d)
This is a good idea, thanks for raising it.
Why 6 hours and not, say, 1 week or even 1 month?
It is very common these days to remain connected for that long, and the UX in having to relogin often is a lot worse.
Mon, May 3
Fri, Apr 30
nice hack/trade-off !
great wording, thanks !
Thu, Apr 29
the fact that algo_min is treated differently than other cases is horrible :-P, but it's not new in this diff, so ok :)
also, in the requirements you should probably put what's the minimum version of swh.core that you need, but that too is not a big deal
Ah, this is an interesting practical problem.
I'm not a fan of changing the spec of SWHID version 1 to make them case insensitive, as it seems to be a significant change (in particular for the code that checks for the syntactic correctness of IDs).
But we can totally add a "SHOULD" section to the resolvers part of the spec recommending (but not mandating) that resolvers treat core SWHIDs as case insensitive. (Of course all the contextual parts cannot be considered case insensitive.)
Wed, Apr 28
Tue, Apr 27
Mon, Apr 26
Mon, Apr 19
Sat, Apr 17
I'm confused about the status of this task. I've just rebuilt the docs for docs.s.o and it says "build succeeded, 83 warnings.". So is the fix for this not yet "deployed" somehow? Also, why is the build succeeding even with all those warnings? Because as long as that's the case, we will for sure keep reintroducing warnings as time goes by.
Fri, Apr 16
@rdicosmo great summary, I'm certainly on that page :)
but adding an email field (auto filled for registered users) to send a notification after the origin was loaded seems a good tradeoff. To implement the email notification, we will have to add a journal client in swh-web processing origin visit messages.
Thu, Apr 15
Oh, and now that we have user profile pages, we should have a list of "my" save code now requests with their status visible in the user profile, for those who want to check synchronously the status of their requests (and might have disabled email notifications).
It would be desirable to provide the user with feedback that helps fix the issue.
Thanks. Can you please make a release after landing this, so that docs.s.o gets updated?
Wed, Apr 14
Sure! My apologies @Hakimb, but it's thank to your work that we have realized what was the right fate for this task.
@seirl, @vlorentz: I see your point, and I agree. We should never have used /nested/paths for this API.
Maybe we should just reconsider this and, one @Hakimb is ready with a new traversal language proposal, we can map it to a better REST API that uses query parameters, and deal properly with 4xx return codes.
Most of my comments are minor/nice to have, although I'd like to be able to pass queries directly on the CLI.
Mon, Apr 12
@vsellier: ack on the outboarding, that is actionable as of now.
Thanks for this!
Thu, Apr 8
ok, so @Hakimb: go for no default value. If the query param is not passed, the visit will not stop before the end. If it's given, it will stop once the limit is reached. Call the query param ?max_edges. You will find that the java code already keeps track of the number of edges traversed, so you should just need to compare with that.
To complement what @vlorentz mentioned, we should actually stop the visit after the maximum number of edges has been reached, because it is keep doing the visit (no matter how many results are returned after it) that can DoS the swh-graph backend.
Apr 7 2021
(good catch also for the missing "$@" in the last invocation)
@ardumont we briefly discussed this a while ago with @olasd. I think the proposed solution was indeed to have a separate queue (and workers) for "save code now" request, but not necessarily one separate queue per loader, because the current priority system wasn't considered to be "fast enough". Maybe we can discuss this briefly with him and synthesize here what you come up with?
Apr 6 2021
No, swh identify is correct, as all SWH CLI commands register as sub-commands of the main swh executable.
also, can you add tests verifying that calling the API without an argument does in fact return 400 error?
duplicate with T3160
Apr 2 2021
@anlambert it looks like we're thinking at the same placement for the link that open the permalink box. The main difference seems to be "modal popup" v. "drop-down section" (that makes the rest of the page scroll down). Maybe you can just try both and see what looks best?
Apr 1 2021
Adding both something (the animation) and an optional checkbox to hide (because it is potentially annoying in the long run) does not sound like a great UX.
Mar 31 2021
Mar 30 2021
awesome, thanks @joenio ! you can also drop by our other devel communication channel if you want to discuss this in other ways: https://www.softwareheritage.org/community/developers/
Hey, yes, we want to have one, but nobody is working it at the moment, and we rather have someone knowledgeable with that ecosystem to work on it. So, if you're interested, you're more than welcome to help there! (And thank you in advance.)
Mar 29 2021
Mar 27 2021
Mar 26 2021
reopening, as ideally we'd like to have run the entire ORC export once to completion before closing
Mar 23 2021
Mar 22 2021
Now that this is (optionally) done by swh-web, I don't think we want to implement it in swh-graph too.
Mar 21 2021
While you are at it, and as a minor point, please also double check your commit message, it doesn't match our conventions (e.g., it is in passive voice, while it shouldn't).
Mar 20 2021
Mar 19 2021
Please do not claim tasks @shivam2003, just submit a patch fixing the issue when you have one. Thanks.