From: Linus Arver <linusa@google.com>
To: Junio C Hamano <gitster@pobox.com>,
Linus Arver via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Christian Couder <chriscool@tuxfamily.org>,
Emily Shaffer <nasamuffin@google.com>,
Josh Steadmon <steadmon@google.com>,
"Randall S. Becker" <rsbecker@nexbridge.com>
Subject: Re: [PATCH v3 05/10] trailer: make trailer_info struct private
Date: Fri, 02 Feb 2024 17:09:12 -0800 [thread overview]
Message-ID: <owlycyte1hhj.fsf@fine.c.googlers.com> (raw)
In-Reply-To: <xmqqplxgyq7f.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> "Linus Arver via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> Make this struct private by putting its definition inside trailer.c.
>> This has two benefits:
>>
>> (1) it makes the surface area of the public facing
>> interface (trailer.h) smaller, and
>>
>> (2) external API users are unable to peer inside this struct (because
>> it is only ever exposed as an opaque pointer).
>
> At the cost of an extra pointer dereference every time the member of
> the struct is accessed, plus the cost of allocation/deallocation.
Added to commit message for v4, thanks.
> Which may not be a huge deal, but I wonder if the approach to name
> the member of the outer struct with "private" that seems to be used
> in other parts of the code (e.g. the .private_size member in the
> hashmap structure, the .refs_private member in the repository
> structure) or even a documented convention (e.g. raw_object_store),
> might be more appropriate here.
Having gotten my hands dirty with the pimpl idiom, I think possibly the
best thing about it is that the compiler can tell me exactly where
every Git subsystem outside of trailer.c is accessing members inside the
(newly private) struct. So it's great for checking existing usage of how
things are used already, day-to-day. Not being well-versed in shortlog
or sequencer internals, these warnings from the compiler for these
functions (trying to peer through the opaque pointer) have been very
informative.
I think it would be reasonable to drop the idiom if the additional
performance costs (pointer dereference, allocation/deallocation) are too
much to bear. For the trailer subsystem I don't see an immediate need to
focus on performance though, so I think it's fine for now.
> If Coccinelle works well (which we
> may be having some trouble with --- cf. <xmqq1q9ybsnl.fsf@gitster.g>),
> we should be able to catch external accesses without having to hide
> the implementation details via an extra pointer dereference.
That's true. But that would only work for trailer API users inside the
Git codebase. Eventually I envision projects external to Git using
<trailer.h>, and in that scenario we would _really_ not want to let
these external users peek inside structs with members named "private" or
"internal" in name only. Murphy's law suggests those external users will
(naughtily) depend on the internals, and that would place an undue
burden on us if we ever wanted to make large changes to these (public)
structs because we might break them.
Another thing to consider is that if our API users ever want to get more
flexibility out of it, they would immediately come to us if we used the
pimpl idiom (our users are bound by exactly how we define the API). If
the structs were public, then they would be free to implement new
functionality to extend the API on their own, without ever letting us
know. If there are folks making small (unofficial) extensions to the
API, I want that to happen _in_ this project, not outside.
In summary what I'm saying is that this idiom gives very strong guidance
for desining an API for both Git-internal and external-to-Git usage. I
think for at least the trailer subsystem it's worth trying out. I've
pointed out some of the same points in the cover letter also.
>> @@ -176,11 +176,12 @@ static void interpret_trailers(const struct process_trailer_options *opts,
>> strbuf_release(&trailer_block);
>>
>> free_trailers(&head);
>> - trailer_info_release(&info);
>>
>> /* Print the lines after the trailers as is */
>> if (!opts->only_trailers)
>> - fwrite(sb.buf + info.trailer_block_end, 1, sb.len - info.trailer_block_end, outfile);
>> + fwrite(sb.buf + trailer_block_end(info), 1, sb.len - trailer_block_end(info), outfile);
>> +
>> + trailer_info_release(info);
>
> Interesting. Is this an indenendent bugfix even if we decided not
> to take this patch?
Nice catch!
> No, I have not fully decided to be negative on
> the move this entire patch makes (even though I am leaning towards
> saying so). Just hypothetically, even if we wanted to keep "info"
> here as a structure and not a pointer to an opaque structure,
> doesn't this hunk fix a real bug?
>
> Well, technically, not quite, because the members referenced in that
> if (.only_trailers) block are still live in the info struct. But it
> still smells wrong to access info.* after calling _release() on it,
> and this fix should come before "info" is turned from an instance to
> a pointer, I would say.
I've promoted this change into a bugfix patch as the very first patch
for the next reroll. Thanks.
>> diff --git a/trailer.h b/trailer.h
>> index a7599067acc..e19ddf84e64 100644
>> --- a/trailer.h
>> +++ b/trailer.h
>> @@ -4,6 +4,8 @@
>> #include "list.h"
>> #include "strbuf.h"
>>
>> +struct trailer_info;
>> +
>> enum trailer_where {
>> WHERE_DEFAULT,
>> WHERE_END,
>> @@ -29,27 +31,6 @@ int trailer_set_where(enum trailer_where *item, const char *value);
>> int trailer_set_if_exists(enum trailer_if_exists *item, const char *value);
>> int trailer_set_if_missing(enum trailer_if_missing *item, const char *value);
>>
>> +size_t trailer_block_start(struct trailer_info *info);
>> +size_t trailer_block_end(struct trailer_info *info);
>> +int blank_line_before_trailer_block(struct trailer_info *info);
>
> And we need new accessors, which is a good change regardless of the
> answer to the "do we really want an extra pointer dereference?
> Shouldn't the existing 'private' and 'internal' label we see below
> sufficient?" question.
I am very surprised with your response here, because I was expecting the
complete opposite reaction from reviewers --- something like
Hmph, we have to write accessor functions now when before we could
just reach inside the struct directly? Isn't this just adding
needless verbosity?
(perhaps with more dissatisfaction). Something tells me you meant "bad
change" but accidentally wrote "good change". Am I correct?
next prev parent reply other threads:[~2024-02-03 1:09 UTC|newest]
Thread overview: 202+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 6:51 [PATCH 00/10] Enrich Trailer API Linus Arver via GitGitGadget
2024-01-10 6:51 ` [PATCH 01/10] trailer: move process_trailers() to interpret-trailers.c Linus Arver via GitGitGadget
2024-01-18 22:26 ` Junio C Hamano
2024-01-19 0:21 ` Linus Arver
2024-01-10 6:51 ` [PATCH 02/10] trailer: include "trailer" term in API functions Linus Arver via GitGitGadget
2024-01-18 22:28 ` Junio C Hamano
2024-01-19 0:12 ` Linus Arver
2024-01-19 0:15 ` Junio C Hamano
2024-01-10 6:51 ` [PATCH 03/10] trailer: unify trailer formatting machinery Linus Arver via GitGitGadget
2024-01-18 22:56 ` Junio C Hamano
2024-01-19 1:12 ` Linus Arver
2024-01-10 6:51 ` [PATCH 04/10] trailer: delete obsolete formatting functions Linus Arver via GitGitGadget
2024-01-19 0:31 ` Junio C Hamano
2024-01-10 6:51 ` [PATCH 05/10] sequencer: use the trailer iterator Linus Arver via GitGitGadget
2024-01-19 0:45 ` Junio C Hamano
2024-01-20 20:04 ` Linus Arver
2024-01-22 23:22 ` Linus Arver
2024-01-10 6:51 ` [PATCH 06/10] trailer: make trailer_info struct private Linus Arver via GitGitGadget
2024-01-19 0:58 ` Junio C Hamano
2024-01-25 19:35 ` Josh Steadmon
2024-01-25 20:32 ` Junio C Hamano
2024-01-10 6:51 ` [PATCH 07/10] trailer: spread usage of "trailer_block" language Linus Arver via GitGitGadget
2024-01-19 1:03 ` Junio C Hamano
2024-01-20 20:09 ` Linus Arver
2024-01-10 6:51 ` [PATCH 08/10] trailer: prepare to move parse_trailers_from_command_line_args() to builtin Linus Arver via GitGitGadget
2024-01-25 23:39 ` Josh Steadmon
2024-01-26 0:14 ` Linus Arver
2024-01-10 6:51 ` [PATCH 09/10] trailer: move arg handling to interpret-trailers.c Linus Arver via GitGitGadget
2024-01-19 1:14 ` Junio C Hamano
2024-01-20 20:14 ` Linus Arver
2024-01-10 6:51 ` [PATCH 10/10] trailer: delete obsolete argument handling code from API Linus Arver via GitGitGadget
2024-01-10 19:45 ` [PATCH 00/10] Enrich Trailer API Junio C Hamano
2024-01-13 1:35 ` Linus Arver
2024-01-14 20:05 ` Linus Arver
2024-01-25 23:54 ` Josh Steadmon
2024-01-26 22:38 ` [PATCH v2 " Linus Arver via GitGitGadget
2024-01-26 22:38 ` [PATCH v2 01/10] trailer: prepare to expose functions as part of API Linus Arver via GitGitGadget
2024-01-30 0:44 ` Josh Steadmon
2024-01-30 2:43 ` Linus Arver
2024-01-26 22:38 ` [PATCH v2 02/10] trailer: move interpret_trailers() to interpret-trailers.c Linus Arver via GitGitGadget
2024-01-26 22:38 ` [PATCH v2 03/10] trailer: unify trailer formatting machinery Linus Arver via GitGitGadget
2024-01-30 0:24 ` Josh Steadmon
2024-01-30 2:58 ` Linus Arver
2024-01-26 22:38 ` [PATCH v2 04/10] trailer: delete obsolete formatting functions Linus Arver via GitGitGadget
2024-01-26 22:38 ` [PATCH v2 05/10] sequencer: use the trailer iterator Linus Arver via GitGitGadget
2024-01-26 22:38 ` [PATCH v2 06/10] trailer: make trailer_info struct private Linus Arver via GitGitGadget
2024-01-26 22:38 ` [PATCH v2 07/10] trailer: spread usage of "trailer_block" language Linus Arver via GitGitGadget
2024-01-26 22:38 ` [PATCH v2 08/10] trailer: prepare to move parse_trailers_from_command_line_args() to builtin Linus Arver via GitGitGadget
2024-01-26 22:38 ` [PATCH v2 09/10] trailer: move arg handling to interpret-trailers.c Linus Arver via GitGitGadget
2024-01-28 5:01 ` Linus Arver
2024-01-28 6:39 ` Linus Arver
2024-01-26 22:38 ` [PATCH v2 10/10] trailer: delete obsolete argument handling code from API Linus Arver via GitGitGadget
2024-01-31 1:22 ` [PATCH v3 00/10] Enrich Trailer API Linus Arver via GitGitGadget
2024-01-31 1:22 ` [PATCH v3 01/10] trailer: prepare to expose functions as part of API Linus Arver via GitGitGadget
2024-01-31 1:22 ` [PATCH v3 02/10] trailer: move interpret_trailers() to interpret-trailers.c Linus Arver via GitGitGadget
2024-01-31 18:54 ` Junio C Hamano
2024-01-31 23:20 ` Linus Arver
2024-01-31 1:22 ` [PATCH v3 03/10] trailer: unify trailer formatting machinery Linus Arver via GitGitGadget
2024-01-31 20:02 ` Josh Steadmon
2024-01-31 23:21 ` Linus Arver
2024-02-01 17:48 ` Junio C Hamano
2024-02-01 18:22 ` Linus Arver
2024-01-31 20:13 ` Junio C Hamano
2024-01-31 22:16 ` Junio C Hamano
2024-02-01 0:46 ` Linus Arver
2024-02-01 1:07 ` Junio C Hamano
2024-02-01 16:41 ` Junio C Hamano
2024-02-01 18:26 ` Linus Arver
2024-02-01 19:21 ` Junio C Hamano
2024-02-02 7:23 ` Linus Arver
2024-02-02 17:26 ` Junio C Hamano
2024-01-31 23:29 ` Linus Arver
2024-01-31 1:22 ` [PATCH v3 04/10] sequencer: use the trailer iterator Linus Arver via GitGitGadget
2024-02-01 18:06 ` Junio C Hamano
2024-02-01 19:14 ` Linus Arver
2024-02-03 0:39 ` Linus Arver
2024-01-31 1:22 ` [PATCH v3 05/10] trailer: make trailer_info struct private Linus Arver via GitGitGadget
2024-02-01 18:49 ` Junio C Hamano
2024-02-03 1:09 ` Linus Arver [this message]
2024-02-03 4:43 ` Junio C Hamano
2024-01-31 1:22 ` [PATCH v3 06/10] trailer: spread usage of "trailer_block" language Linus Arver via GitGitGadget
2024-02-01 18:57 ` Junio C Hamano
2024-02-03 1:37 ` Linus Arver
2024-01-31 1:22 ` [PATCH v3 07/10] trailer: prepare to move parse_trailers_from_command_line_args() to builtin Linus Arver via GitGitGadget
2024-02-01 19:06 ` Junio C Hamano
2024-01-31 1:22 ` [PATCH v3 08/10] trailer: move arg handling to interpret-trailers.c Linus Arver via GitGitGadget
2024-02-01 22:23 ` Junio C Hamano
2024-02-03 1:48 ` Linus Arver
2024-02-06 1:01 ` Linus Arver
2024-01-31 1:22 ` [PATCH v3 09/10] trailer: delete obsolete argument handling code from API Linus Arver via GitGitGadget
2024-02-01 22:25 ` Junio C Hamano
2024-02-03 1:40 ` Linus Arver
2024-01-31 1:22 ` [PATCH v3 10/10] trailer: introduce "template" term for readability Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 00/28] Enrich Trailer API Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 01/28] trailer: free trailer_info _after_ all related usage Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 02/28] shortlog: add test for de-duplicating folded trailers Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 03/28] trailer: prepare to expose functions as part of API Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 04/28] trailer: move interpret_trailers() to interpret-trailers.c Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 05/28] trailer: start preparing for formatting unification Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 06/28] trailer_info_get(): reorder parameters Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 07/28] format_trailers(): use strbuf instead of FILE Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 08/28] format_trailer_info(): move "fast path" to caller Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 09/28] format_trailers_from_commit(): indirectly call trailer_info_get() Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 10/28] format_trailer_info(): use trailer_item objects Linus Arver via GitGitGadget
2024-02-09 21:53 ` Junio C Hamano
2024-02-13 16:35 ` Linus Arver
2024-02-06 5:12 ` [PATCH v4 11/28] format_trailer_info(): drop redundant unfold_value() Linus Arver via GitGitGadget
2024-02-09 21:54 ` Junio C Hamano
2024-02-06 5:12 ` [PATCH v4 12/28] format_trailer_info(): append newline for non-trailer lines Linus Arver via GitGitGadget
2024-02-09 21:53 ` Junio C Hamano
2024-02-12 23:37 ` Christian Couder
2024-02-13 16:49 ` Linus Arver
2024-02-06 5:12 ` [PATCH v4 13/28] trailer: begin formatting unification Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 14/28] format_trailer_info(): teach it about opts->trim_empty Linus Arver via GitGitGadget
2024-02-12 23:38 ` Christian Couder
2024-02-13 17:05 ` Linus Arver
2024-02-13 17:21 ` Christian Couder
2024-02-06 5:12 ` [PATCH v4 15/28] format_trailer_info(): avoid double-printing the separator Linus Arver via GitGitGadget
2024-02-12 23:38 ` Christian Couder
2024-02-13 17:21 ` Linus Arver
2024-02-13 17:25 ` Christian Couder
2024-02-13 19:52 ` Linus Arver
2024-03-15 5:31 ` Linus Arver
2024-02-13 20:41 ` Kristoffer Haugsbakk
2024-02-06 5:12 ` [PATCH v4 16/28] trailer: finish formatting unification Linus Arver via GitGitGadget
2024-02-09 21:53 ` Junio C Hamano
2024-02-12 23:38 ` Christian Couder
2024-02-13 17:30 ` Linus Arver
2024-02-06 5:12 ` [PATCH v4 17/28] trailer: teach iterator about non-trailer lines Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 18/28] sequencer: use the trailer iterator Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 19/28] trailer: make trailer_info struct private Linus Arver via GitGitGadget
2024-02-09 21:53 ` Junio C Hamano
2024-02-13 17:36 ` Linus Arver
2024-02-12 23:38 ` Christian Couder
2024-02-13 17:41 ` Linus Arver
2024-02-06 5:12 ` [PATCH v4 20/28] trailer: retire trailer_info_get() from API Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 21/28] trailer: spread usage of "trailer_block" language Linus Arver via GitGitGadget
2024-02-12 23:39 ` Christian Couder
2024-02-13 17:47 ` Linus Arver
2024-02-06 5:12 ` [PATCH v4 22/28] trailer: prepare to delete "parse_trailers_from_command_line_args()" Linus Arver via GitGitGadget
2024-02-12 23:39 ` Christian Couder
2024-02-13 17:53 ` Linus Arver
2024-02-06 5:12 ` [PATCH v4 23/28] trailer: add new helper functions to API Linus Arver via GitGitGadget
2024-02-12 23:39 ` Christian Couder
2024-02-13 17:57 ` Linus Arver
2024-02-06 5:12 ` [PATCH v4 24/28] trailer_add_arg_item(): drop new_trailer_item usage Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 25/28] trailer: deprecate "new_trailer_item" struct from API Linus Arver via GitGitGadget
2024-02-06 5:12 ` [PATCH v4 26/28] trailer: unify "--trailer ..." arg handling Linus Arver via GitGitGadget
2024-02-12 23:39 ` Christian Couder
2024-02-13 18:12 ` Linus Arver
2024-02-06 5:12 ` [PATCH v4 27/28] trailer_set_*(): put out parameter at the end Linus Arver via GitGitGadget
2024-02-12 23:39 ` Christian Couder
2024-02-13 18:14 ` Linus Arver
2024-02-06 5:12 ` [PATCH v4 28/28] trailer: introduce "template" term for readability Linus Arver via GitGitGadget
2024-02-12 23:40 ` Christian Couder
2024-02-13 18:20 ` Linus Arver
2024-02-12 23:37 ` [PATCH v4 00/28] Enrich Trailer API Christian Couder
2024-02-13 0:11 ` Junio C Hamano
2024-02-13 6:55 ` Christian Couder
2024-02-13 17:30 ` Junio C Hamano
2024-02-13 20:25 ` Christian Couder
2024-02-16 2:25 ` Linus Arver
2024-02-13 19:39 ` Linus Arver
2024-02-13 19:57 ` Junio C Hamano
2024-02-13 20:25 ` Kristoffer Haugsbakk
2024-02-13 20:55 ` Christian Couder
2024-02-16 2:17 ` Linus Arver
2024-02-16 23:09 ` [PATCH v5 0/9] " Linus Arver via GitGitGadget
2024-02-16 23:09 ` [PATCH v5 1/9] trailer: free trailer_info _after_ all related usage Linus Arver via GitGitGadget
2024-02-16 23:09 ` [PATCH v5 2/9] shortlog: add test for de-duplicating folded trailers Linus Arver via GitGitGadget
2024-02-16 23:09 ` [PATCH v5 3/9] trailer: prepare to expose functions as part of API Linus Arver via GitGitGadget
2024-02-19 21:31 ` Christian Couder
2024-02-29 22:33 ` Linus Arver
2024-02-29 23:21 ` Junio C Hamano
2024-02-29 23:53 ` Linus Arver
2024-02-16 23:09 ` [PATCH v5 4/9] trailer: move interpret_trailers() to interpret-trailers.c Linus Arver via GitGitGadget
2024-02-16 23:09 ` [PATCH v5 5/9] trailer: start preparing for formatting unification Linus Arver via GitGitGadget
2024-02-19 21:31 ` Christian Couder
2024-02-29 22:53 ` Linus Arver
2024-02-16 23:09 ` [PATCH v5 6/9] trailer_info_get(): reorder parameters Linus Arver via GitGitGadget
2024-02-16 23:09 ` [PATCH v5 7/9] format_trailers(): use strbuf instead of FILE Linus Arver via GitGitGadget
2024-02-16 23:09 ` [PATCH v5 8/9] format_trailer_info(): move "fast path" to caller Linus Arver via GitGitGadget
2024-02-16 23:09 ` [PATCH v5 9/9] format_trailers_from_commit(): indirectly call trailer_info_get() Linus Arver via GitGitGadget
2024-02-19 21:32 ` Christian Couder
2024-02-29 23:00 ` Linus Arver
2024-02-19 21:40 ` [PATCH v5 0/9] Enrich Trailer API Christian Couder
2024-03-01 0:14 ` [PATCH v6 " Linus Arver via GitGitGadget
2024-03-01 0:14 ` [PATCH v6 1/9] trailer: free trailer_info _after_ all related usage Linus Arver via GitGitGadget
2024-03-01 0:14 ` [PATCH v6 2/9] shortlog: add test for de-duplicating folded trailers Linus Arver via GitGitGadget
2024-03-01 0:14 ` [PATCH v6 3/9] trailer: rename functions to use 'trailer' Linus Arver via GitGitGadget
2024-03-01 0:14 ` [PATCH v6 4/9] trailer: move interpret_trailers() to interpret-trailers.c Linus Arver via GitGitGadget
2024-03-01 0:14 ` [PATCH v6 5/9] trailer: reorder format_trailers_from_commit() parameters Linus Arver via GitGitGadget
2024-03-01 0:14 ` [PATCH v6 6/9] trailer_info_get(): reorder parameters Linus Arver via GitGitGadget
2024-03-01 0:14 ` [PATCH v6 7/9] format_trailers(): use strbuf instead of FILE Linus Arver via GitGitGadget
2024-03-01 0:14 ` [PATCH v6 8/9] format_trailer_info(): move "fast path" to caller Linus Arver via GitGitGadget
2024-03-01 0:14 ` [PATCH v6 9/9] format_trailers_from_commit(): indirectly call trailer_info_get() Linus Arver via GitGitGadget
2024-03-05 18:03 ` [PATCH v6 0/9] Enrich Trailer API Junio C Hamano
2024-03-05 19:07 ` Josh Steadmon
2024-03-05 19:41 ` Junio C Hamano
2024-03-06 14:41 ` Christian Couder
2024-03-06 16:59 ` Junio C Hamano
2024-03-06 17:09 ` Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=owlycyte1hhj.fsf@fine.c.googlers.com \
--to=linusa@google.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=nasamuffin@google.com \
--cc=rsbecker@nexbridge.com \
--cc=steadmon@google.com \
/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.
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).