unofficial mirror of meta@public-inbox.org
 help / color / mirror / Atom feed
* RFC: hooks in public-inbox-watch
@ 2022-05-12 18:04 Konstantin Ryabitsev
  2022-05-12 19:38 ` Eric Wong
  0 siblings, 1 reply; 3+ messages in thread
From: Konstantin Ryabitsev @ 2022-05-12 18:04 UTC (permalink / raw)
  To: meta

Hi, all:

What do you think about a mechanism to run hooks at the stage right before
public-inbox-watch adds a new message to the archive? One feature that would
be neat is to search archives for all instances of the same patch using its
$(git-patch-id --stable) and adding a header, e.g.:

    X-Git-Patch-ID: 19c05284cea20b72b44c2b7e6cfd782a6a860cf1 0000000000000000000000000000000000000000

I know this can be done at the postfix stage, but seems like it would be more
efficient at the ingestion stage.

Maybe even instead of a hook this could be a native public-inbox feature, with
this header being indexed by default?

-K

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: RFC: hooks in public-inbox-watch
  2022-05-12 18:04 RFC: hooks in public-inbox-watch Konstantin Ryabitsev
@ 2022-05-12 19:38 ` Eric Wong
  2022-05-12 19:54   ` Konstantin Ryabitsev
  0 siblings, 1 reply; 3+ messages in thread
From: Eric Wong @ 2022-05-12 19:38 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: meta

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> Hi, all:
> 
> What do you think about a mechanism to run hooks at the stage right before
> public-inbox-watch adds a new message to the archive? One feature that would
> be neat is to search archives for all instances of the same patch using its
> $(git-patch-id --stable) and adding a header, e.g.:
> 
>     X-Git-Patch-ID: 19c05284cea20b72b44c2b7e6cfd782a6a860cf1 0000000000000000000000000000000000000000

There shouldn't be any need for a header.  I've been meaning to
teach -index to use git-patch-id and index it's output, anyways.
That would work for old messages, too.

> I know this can be done at the postfix stage, but seems like it would be more
> efficient at the ingestion stage.
> 
> Maybe even instead of a hook this could be a native public-inbox feature, with
> this header being indexed by default?

I've always tried as hard as possible to avoid adding new
headers or extra data; especially when we have a common and
stable tool to generate it.  Another danger is a malicious
client could also be introducing wrong ones to confuse searches.

Thanks.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: RFC: hooks in public-inbox-watch
  2022-05-12 19:38 ` Eric Wong
@ 2022-05-12 19:54   ` Konstantin Ryabitsev
  0 siblings, 0 replies; 3+ messages in thread
From: Konstantin Ryabitsev @ 2022-05-12 19:54 UTC (permalink / raw)
  To: Eric Wong; +Cc: meta

On Thu, May 12, 2022 at 07:38:59PM +0000, Eric Wong wrote:
> Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> > Hi, all:
> > 
> > What do you think about a mechanism to run hooks at the stage right before
> > public-inbox-watch adds a new message to the archive? One feature that would
> > be neat is to search archives for all instances of the same patch using its
> > $(git-patch-id --stable) and adding a header, e.g.:
> > 
> >     X-Git-Patch-ID: 19c05284cea20b72b44c2b7e6cfd782a6a860cf1 0000000000000000000000000000000000000000
> 
> There shouldn't be any need for a header.  I've been meaning to
> teach -index to use git-patch-id and index it's output, anyways.
> That would work for old messages, too.

Sure, I'll take that, too. :)

Thanks,
-K

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-05-12 19:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-12 18:04 RFC: hooks in public-inbox-watch Konstantin Ryabitsev
2022-05-12 19:38 ` Eric Wong
2022-05-12 19:54   ` Konstantin Ryabitsev

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).