unofficial mirror of meta@public-inbox.org
 help / color / mirror / Atom feed
* [RFC][PATCH] Config.pm: Add support for mailing list information
@ 2019-05-17  1:45 Eric W. Biederman
  2019-05-18  7:15 ` Eric Wong
  0 siblings, 1 reply; 4+ messages in thread
From: Eric W. Biederman @ 2019-05-17  1:45 UTC (permalink / raw)
  To: Eric Wong; +Cc: meta


The world has turned since I first started following mailing lists and
to my surprise every mailling list that I am subscribed to properly
sets the "List-ID:" mailing list header.  So instead of doing
something clever and flexible I am adding support for looking up
public inbox mailing lists by their mailing list name.

That makes the work needed for each email trivial and easy to understand.
- Parse the "List-ID:" header.
- Lookup in the configuration which mailbox is connected to that
  "List-ID:"
- Deliver the mail to that mailbox.

To that end this change enhances PublicInbox to have an additional
mailbox configuration parameter "list" that holds the mailling list
name.

A method is added to the PublicInbox config object called
lookup_list that given a mailing list name will return
the PublicInbox in the configarion that is configured to
handle that mailing list.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---

Some context.  I have my mailing list email coming in via imap, and I
have a script that looks at List-ID and delivers them to the appropriate
public-inbox.  I am hoping to get my script at least into the PublicInbox
scripts directory.

I have looked and see that you a watchheader directive that effectively
does the same thing that I am doing.  Even so, I think a mailing list
having one or more mailling list names is more fundamental.  A mailing
name is a well supported concept and it differs from an address
in that a mailing list name does not have an "@".

So as part of getting my small changes to your PublicInbox code
to support my email fetching script.  Do you mind the addition
of a mailing list name configuration parameter?

If you don't mind can we apply the patch below?  Do I need to tweak
public-inbox-watch to be able to use the list parameter?  I can't
really test it as my setup is quite different but I am willing to
work things through so that the code is harmonized and people
can benefit from each others improvements.

 lib/PublicInbox/Config.pm | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/lib/PublicInbox/Config.pm b/lib/PublicInbox/Config.pm
index 09f9179b085a..70bd88f51556 100644
--- a/lib/PublicInbox/Config.pm
+++ b/lib/PublicInbox/Config.pm
@@ -25,6 +25,7 @@ sub new {
 
 	# caches
 	$self->{-by_addr} ||= {};
+	$self->{-by_list} ||= {};
 	$self->{-by_name} ||= {};
 	$self->{-by_newsgroup} ||= {};
 	$self->{-no_obfuscate} ||= {};
@@ -84,6 +85,32 @@ sub lookup {
 	_fill($self, $pfx);
 }
 
+sub lookup_list {
+	my ($self, $list) = @_;
+	my $inbox = $self->{-by_list}->{$list};
+	return $inbox if $inbox;
+
+	my $pfx;
+
+	foreach my $k (keys %$self) {
+		$k =~ /\A(publicinbox\.[\w-]+)\.list\z/ or next;
+		my $v = $self->{$k};
+		if (ref($v) eq "ARRAY") {
+			foreach my $alias (@$v) {
+				($alias eq $list) or next;
+				$pfx = $1;
+				last;
+			}
+		} else {
+			($v eq $list) or next;
+			$pfx = $1;
+			last;
+		}
+	}
+	defined $pfx or return;
+	_fill($self, $pfx);
+}
+
 sub lookup_name ($$) {
 	my ($self, $name) = @_;
 	$self->{-by_name}->{$name} || _fill($self, "publicinbox.$name");
@@ -389,7 +416,7 @@ sub _fill {
 	}
 	# TODO: more arrays, we should support multi-value for
 	# more things to encourage decentralization
-	foreach my $k (qw(address altid nntpmirror coderepo hide)) {
+	foreach my $k (qw(address altid nntpmirror coderepo hide list)) {
 		if (defined(my $v = $self->{"$pfx.$k"})) {
 			$ibx->{$k} = _array($v);
 		}
@@ -412,6 +439,10 @@ sub _fill {
 		$self->{-by_addr}->{$lc_addr} = $ibx;
 		$self->{-no_obfuscate}->{$lc_addr} = 1;
 	}
+	foreach (@{$ibx->{list}}) {
+		my $list = $_;
+		$self->{-by_list}->{$list} = $ibx;
+	}
 	if (my $ng = $ibx->{newsgroup}) {
 		$self->{-by_newsgroup}->{$ng} = $ibx;
 	}
-- 
2.17.1


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

* Re: [RFC][PATCH] Config.pm: Add support for mailing list information
  2019-05-17  1:45 [RFC][PATCH] Config.pm: Add support for mailing list information Eric W. Biederman
@ 2019-05-18  7:15 ` Eric Wong
  2019-05-18 15:22   ` Eric W. Biederman
  0 siblings, 1 reply; 4+ messages in thread
From: Eric Wong @ 2019-05-18  7:15 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: meta

"Eric W. Biederman" <ebiederm@xmission.com> wrote:
> 
> The world has turned since I first started following mailing lists and
> to my surprise every mailling list that I am subscribed to properly
> sets the "List-ID:" mailing list header.  So instead of doing
> something clever and flexible I am adding support for looking up
> public inbox mailing lists by their mailing list name.

Agreed, and good to know List-Id is getting standardized on.

> That makes the work needed for each email trivial and easy to understand.
> - Parse the "List-ID:" header.
> - Lookup in the configuration which mailbox is connected to that
>   "List-ID:"
> - Deliver the mail to that mailbox.

This is a great idea.  One great side-effect would be avoiding
the the need to expose the mirror delivery address for server
admins who use -mda for mirroring lists:

https://public-inbox.org/meta/20180612170546.GA5945@chatter/

> To that end this change enhances PublicInbox to have an additional
> mailbox configuration parameter "list" that holds the mailling list
> name.

I think using "listId" in configs would be preferable, as I
think it's clear that we're matching the RFC2919 header and
not any other thing like "X-Mailing-List".

We'll use camelCase for user docs, and only alllowercase for
parsing (consistent with git config naming).  I actually hate
that naming convention of git config keys, so "list_id" for
internal variables.

Spelling: s/mailling/mailing/g (you seem to spell it both ways
throughout the email)

Also, as a Perl user, the word "list" alone is also a bit
ambiguous because it tends to get used interchangeably with
"array"; and it could be confused in my brain as a throwaway
variable.

> A method is added to the PublicInbox config object called
> lookup_list that given a mailing list name will return
> the PublicInbox in the configarion that is configured to
> handle that mailing list.
> 
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
> 
> Some context.  I have my mailing list email coming in via imap, and I
> have a script that looks at List-ID and delivers them to the appropriate
> public-inbox.  I am hoping to get my script at least into the PublicInbox
> scripts directory.
> 
> I have looked and see that you a watchheader directive that effectively
> does the same thing that I am doing.  Even so, I think a mailing list
> having one or more mailling list names is more fundamental.  A mailing
> name is a well supported concept and it differs from an address
> in that a mailing list name does not have an "@".

Yes, for -watch, watchheader is a more flexible variant of this.
listId could be used as a shortcut.

> So as part of getting my small changes to your PublicInbox code
> to support my email fetching script.  Do you mind the addition
> of a mailing list name configuration parameter?
> If you don't mind can we apply the patch below?

Don't mind at all, but I would like some comments in this
email addressed, along with some tests for -mda, at least.

> Do I need to tweak
> public-inbox-watch to be able to use the list parameter?

I think translating the listId directive into a watchheader
regexp will be sufficient.

> I can't
> really test it as my setup is quite different but I am willing to
> work things through so that the code is harmonized and people
> can benefit from each others improvements.

Looks like watchheader is also missing tests :x

>  lib/PublicInbox/Config.pm | 33 ++++++++++++++++++++++++++++++++-
>  1 file changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/PublicInbox/Config.pm b/lib/PublicInbox/Config.pm
> index 09f9179b085a..70bd88f51556 100644
> --- a/lib/PublicInbox/Config.pm
> +++ b/lib/PublicInbox/Config.pm
> @@ -25,6 +25,7 @@ sub new {
>  
>  	# caches
>  	$self->{-by_addr} ||= {};
> +	$self->{-by_list} ||= {};

-by_list_id

>  	$self->{-by_name} ||= {};
>  	$self->{-by_newsgroup} ||= {};
>  	$self->{-no_obfuscate} ||= {};
> @@ -84,6 +85,32 @@ sub lookup {
>  	_fill($self, $pfx);
>  }
>  
> +sub lookup_list {

lookup_list_id

> +	my ($self, $list) = @_;
> +	my $inbox = $self->{-by_list}->{$list};
> +	return $inbox if $inbox;

"my $ibx"

I've been starting to standardize on $ibx as the identifier for
PublicInbox::Inbox references (and maybe leave $inbox for
human-readable names).

> +	foreach my $k (keys %$self) {
> +		$k =~ /\A(publicinbox\.[\w-]+)\.list\z/ or next;

                                              \.listid\z/

> +		my $v = $self->{$k};
> +		if (ref($v) eq "ARRAY") {
> +			foreach my $alias (@$v) {
> +				($alias eq $list) or next;
> +				$pfx = $1;
> +				last;
> +			}
> +		} else {
> +			($v eq $list) or next;
> +			$pfx = $1;
> +			last;
> +		}

It looks these "eq" comparisons should be case-insensitive:

	https://tools.ietf.org/html/rfc2919#section-6

> +	}
> +	defined $pfx or return;
> +	_fill($self, $pfx);
> +}
> +
>  sub lookup_name ($$) {
>  	my ($self, $name) = @_;
>  	$self->{-by_name}->{$name} || _fill($self, "publicinbox.$name");
> @@ -389,7 +416,7 @@ sub _fill {
>  	}
>  	# TODO: more arrays, we should support multi-value for
>  	# more things to encourage decentralization
> -	foreach my $k (qw(address altid nntpmirror coderepo hide)) {
> +	foreach my $k (qw(address altid nntpmirror coderepo hide list)) {
>  		if (defined(my $v = $self->{"$pfx.$k"})) {
>  			$ibx->{$k} = _array($v);
>  		}
> @@ -412,6 +439,10 @@ sub _fill {
>  		$self->{-by_addr}->{$lc_addr} = $ibx;
>  		$self->{-no_obfuscate}->{$lc_addr} = 1;
>  	}
> +	foreach (@{$ibx->{list}}) {
> +		my $list = $_;
> +		$self->{-by_list}->{$list} = $ibx;
> +	}

No sense in "my $list = $_"; either "foreach my $list_id" for
larger loops, or use $_ for tiny loops.

Anyways, great idea, needs some minor tweaks.  Thanks!

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

* Re: [RFC][PATCH] Config.pm: Add support for mailing list information
  2019-05-18  7:15 ` Eric Wong
@ 2019-05-18 15:22   ` Eric W. Biederman
  2019-06-13  0:45     ` Eric Wong
  0 siblings, 1 reply; 4+ messages in thread
From: Eric W. Biederman @ 2019-05-18 15:22 UTC (permalink / raw)
  To: Eric Wong; +Cc: meta

Eric Wong <e@80x24.org> writes:

> "Eric W. Biederman" <ebiederm@xmission.com> wrote:
>> 
>> The world has turned since I first started following mailing lists and
>> to my surprise every mailling list that I am subscribed to properly
>> sets the "List-ID:" mailing list header.  So instead of doing
>> something clever and flexible I am adding support for looking up
>> public inbox mailing lists by their mailing list name.
>
> Agreed, and good to know List-Id is getting standardized on.
>
>> That makes the work needed for each email trivial and easy to understand.
>> - Parse the "List-ID:" header.
>> - Lookup in the configuration which mailbox is connected to that
>>   "List-ID:"
>> - Deliver the mail to that mailbox.
>
> This is a great idea.  One great side-effect would be avoiding
> the the need to expose the mirror delivery address for server
> admins who use -mda for mirroring lists:
>
> https://public-inbox.org/meta/20180612170546.GA5945@chatter/


Yes. I see.  I can easily have it do that.  For email mirrors
this works very well.

>> To that end this change enhances PublicInbox to have an additional
>> mailbox configuration parameter "list" that holds the mailling list
>> name.
>
> I think using "listId" in configs would be preferable, as I
> think it's clear that we're matching the RFC2919 header and
> not any other thing like "X-Mailing-List".
>
> We'll use camelCase for user docs, and only alllowercase for
> parsing (consistent with git config naming).  I actually hate
> that naming convention of git config keys, so "list_id" for
> internal variables.
>
> Spelling: s/mailling/mailing/g (you seem to spell it both ways
> throughout the email)

Got it.  I think I am suffering from a bit of new Daddy syndrome.
I will clean that up before I resubmit.

> Also, as a Perl user, the word "list" alone is also a bit
> ambiguous because it tends to get used interchangeably with
> "array"; and it could be confused in my brain as a throwaway
> variable.

Makes perfect sense.

>> A method is added to the PublicInbox config object called
>> lookup_list that given a mailing list name will return
>> the PublicInbox in the configarion that is configured to
>> handle that mailing list.
>> 
>> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>> ---
>> 
>> Some context.  I have my mailing list email coming in via imap, and I
>> have a script that looks at List-ID and delivers them to the appropriate
>> public-inbox.  I am hoping to get my script at least into the PublicInbox
>> scripts directory.
>> 
>> I have looked and see that you a watchheader directive that effectively
>> does the same thing that I am doing.  Even so, I think a mailing list
>> having one or more mailling list names is more fundamental.  A mailing
>> name is a well supported concept and it differs from an address
>> in that a mailing list name does not have an "@".
>
> Yes, for -watch, watchheader is a more flexible variant of this.
> listId could be used as a shortcut.

Yes.  I will se what I can arrange for updating -watch and -mda.

>> So as part of getting my small changes to your PublicInbox code
>> to support my email fetching script.  Do you mind the addition
>> of a mailing list name configuration parameter?
>> If you don't mind can we apply the patch below?
>
> Don't mind at all, but I would like some comments in this
> email addressed, along with some tests for -mda, at least.

Noted I will aim at getting that done.

>> Do I need to tweak
>> public-inbox-watch to be able to use the list parameter?
>
> I think translating the listId directive into a watchheader
> regexp will be sufficient.

Yes.  That should be straight forward.  I will do that.

>> I can't
>> really test it as my setup is quite different but I am willing to
>> work things through so that the code is harmonized and people
>> can benefit from each others improvements.
>
> Looks like watchheader is also missing tests :x
>
>>  lib/PublicInbox/Config.pm | 33 ++++++++++++++++++++++++++++++++-
>>  1 file changed, 32 insertions(+), 1 deletion(-)
>> 
>> diff --git a/lib/PublicInbox/Config.pm b/lib/PublicInbox/Config.pm
>> index 09f9179b085a..70bd88f51556 100644
>> --- a/lib/PublicInbox/Config.pm
>> +++ b/lib/PublicInbox/Config.pm
>> @@ -25,6 +25,7 @@ sub new {
>>  
>>  	# caches
>>  	$self->{-by_addr} ||= {};
>> +	$self->{-by_list} ||= {};
>
> -by_list_id

ack

>>  	$self->{-by_name} ||= {};
>>  	$self->{-by_newsgroup} ||= {};
>>  	$self->{-no_obfuscate} ||= {};
>> @@ -84,6 +85,32 @@ sub lookup {
>>  	_fill($self, $pfx);
>>  }
>>  
>> +sub lookup_list {
>
> lookup_list_id

ack

>> +	my ($self, $list) = @_;
>> +	my $inbox = $self->{-by_list}->{$list};
>> +	return $inbox if $inbox;
>
> "my $ibx"
>
> I've been starting to standardize on $ibx as the identifier for
> PublicInbox::Inbox references (and maybe leave $inbox for
> human-readable names).
>

ack.

>> +	foreach my $k (keys %$self) {
>> +		$k =~ /\A(publicinbox\.[\w-]+)\.list\z/ or next;
>
>                                               \.listid\z/
ack

>> +		my $v = $self->{$k};
>> +		if (ref($v) eq "ARRAY") {
>> +			foreach my $alias (@$v) {
>> +				($alias eq $list) or next;
>> +				$pfx = $1;
>> +				last;
>> +			}
>> +		} else {
>> +			($v eq $list) or next;
>> +			$pfx = $1;
>> +			last;
>> +		}
>
> It looks these "eq" comparisons should be case-insensitive:
>
> 	https://tools.ietf.org/html/rfc2919#section-6

Interesting.  I have yet to see it matter.  But it isn't hard
to change the code to do:
		(lc($v) eq lc($list).

>> +	}
>> +	defined $pfx or return;
>> +	_fill($self, $pfx);
>> +}
>> +
>>  sub lookup_name ($$) {
>>  	my ($self, $name) = @_;
>>  	$self->{-by_name}->{$name} || _fill($self, "publicinbox.$name");
>> @@ -389,7 +416,7 @@ sub _fill {
>>  	}
>>  	# TODO: more arrays, we should support multi-value for
>>  	# more things to encourage decentralization
>> -	foreach my $k (qw(address altid nntpmirror coderepo hide)) {
>> +	foreach my $k (qw(address altid nntpmirror coderepo hide list)) {
>>  		if (defined(my $v = $self->{"$pfx.$k"})) {
>>  			$ibx->{$k} = _array($v);
>>  		}
>> @@ -412,6 +439,10 @@ sub _fill {
>>  		$self->{-by_addr}->{$lc_addr} = $ibx;
>>  		$self->{-no_obfuscate}->{$lc_addr} = 1;
>>  	}
>> +	foreach (@{$ibx->{list}}) {
>> +		my $list = $_;
>> +		$self->{-by_list}->{$list} = $ibx;
>> +	}
>
> No sense in "my $list = $_"; either "foreach my $list_id" for
> larger loops, or use $_ for tiny loops.
>
> Anyways, great idea, needs some minor tweaks.  Thanks!

Will make them and get this posted again.

Eric

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

* Re: [RFC][PATCH] Config.pm: Add support for mailing list information
  2019-05-18 15:22   ` Eric W. Biederman
@ 2019-06-13  0:45     ` Eric Wong
  0 siblings, 0 replies; 4+ messages in thread
From: Eric Wong @ 2019-06-13  0:45 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: meta

"Eric W. Biederman" <ebiederm@xmission.com> wrote:
> Will make them and get this posted again.

Hey, just wondering where you are with this List-Id work.

I'm planning to make some improvements to the -watch code in
a few days (I hope).  I'd probably use this feature myself,
so I can take it over and let you focus on other stuff :)

Thanks.

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

end of thread, other threads:[~2019-06-13  0:45 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-05-17  1:45 [RFC][PATCH] Config.pm: Add support for mailing list information Eric W. Biederman
2019-05-18  7:15 ` Eric Wong
2019-05-18 15:22   ` Eric W. Biederman
2019-06-13  0:45     ` Eric Wong

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