unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Miguel Ángel Arruga Vivas" <rosen644835@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 44193@debbugs.gnu.org
Subject: [bug#44193] [PATCH 0/1] 'guix publish --cache' can publish items not yet cached
Date: Sun, 25 Oct 2020 14:11:37 +0100	[thread overview]
Message-ID: <87v9ey5u2e.fsf@gmail.com> (raw)
In-Reply-To: <20201024144929.4529-1-ludo@gnu.org> ("Ludovic Courtès"'s message of "Sat, 24 Oct 2020 16:49:29 +0200")

Hi!

Just one general comment about this issue:

Ludovic Courtès <ludo@gnu.org> writes:
> Thus, the first narinfo request for an item would always return 404;
> one would have to wait until the item is baked to get 200 and download
> the substitute.

I'd argue that returning unconditionally the 404 is a problem.  If the
nar is getting baked, I guess that a 202[1] would be the appropriate
answer, and I'd leave the 404 for invalid store paths[2].  This way the
client could implement more policies: the classic timeout, but also, for
example, it might check other servers before checking once again if
nobody else has it, or directly wait until a 404 is reached.  WDYT?

Happy hacking!
Miguel

[1] Section 10.2.3 from https://www.ietf.org/rfc/rfc2616.txt
[2] I understand that it isn't at all a bad usage of the 404, as it
    explicitly says that the condition might be temporary, but on the
    other hand I don't know how could that extra information be used by
    a rogue client in any way worse than it could do right now, as the
    server process is doing the same computation more or less in both
    cases.




  parent reply	other threads:[~2020-10-25 13:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-24 14:49 [bug#44193] [PATCH 0/1] 'guix publish --cache' can publish items not yet cached Ludovic Courtès
2020-10-24 14:54 ` [bug#44193] [PATCH 1/1] publish: Add '--cache-bypass-threshold' Ludovic Courtès
2020-10-28 15:26   ` bug#44193: " Ludovic Courtès
2020-10-25 13:11 ` Miguel Ángel Arruga Vivas [this message]
2020-10-25 16:49   ` [bug#44193] [PATCH 0/1] 'guix publish --cache' can publish items not yet cached Ludovic Courtès
2020-10-25 17:30     ` Miguel Ángel Arruga Vivas
2020-10-26 10:50       ` Ludovic Courtès
2020-10-27 19:19         ` Miguel Ángel Arruga Vivas
2020-10-28  9:39           ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v9ey5u2e.fsf@gmail.com \
    --to=rosen644835@gmail.com \
    --cc=44193@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).