From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: VA <dev+notmuch@indigo.re>, notmuch@notmuchmail.org
Subject: Re: [PATCH] python: bind add_property/remove_property and related methods
Date: Sun, 16 Jun 2019 02:52:52 +0300 [thread overview]
Message-ID: <87pnnecsob.fsf@fifthhorseman.net> (raw)
In-Reply-To: <a4cdd1cb-fa28-fad5-dbbf-c7a42f7c0199@indigo.re>
[-- Attachment #1: Type: text/plain, Size: 2537 bytes --]
On Fri 2019-06-14 22:34:16 +0200, VA wrote:
> The wiki would serve to advertise each projects interests, and if some
> other project has a common interest, they could get together to
> standardize it in the interest of both projects?
Makes sense to me. Each one then gets to deal with the legacy of having
the old "x-<project>-foo" property and new standard form "foo", which is
kind of annoying bookkeeping work, but maybe not too hard to do. I'm
sure someone can write a converter script pretty simply once
"x-<project>-foo" is fully deprecated in such a transition.
> IMHO, libnotmuch should stay focused on the core: indexing and tagging,
> avoid becoming bloated by staying minimal, doing one thing well. Else,
> it would not deserve the "notmuch" name anymore!
>
> However, maybe this could be in some extras, maybe a separate
> notmuch-extensions library.
Hm, i'm not so worried about keeping the semantics of the "notmuch" name
:P
If some useful feature can happen most efficiently at indexing time, and
the index is built by the library, i think the ecosystem is best served
by making sure that libnotmuch can just do it directly.
> For messages with a plain text part, I'm taking the first 100 chars. If
> there's no plain text part but an HTML part, I'm using some random
> html2text library (https://github.com/Alir3z4/html2text) and take the
> first 100 chars.
makes sense, thanks for the simple and straightforward description. I
assume if the message has neither a text/plain nor a text/html part,
then no property is added. And for messages with multiple text/plain
parts, you just take the first text/plain part encountered in a
depth-first traversal of the MIME tree?
> Here's what we could add:
>
> As a general rule, an application MUST prefix their own property names
> with "x-<project>-". It is recommended to report an application's
> properties on the notmuch wiki, to open collaboration with other
> projects having common use cases, ultimately opening to standardization
> outside a project's namespace.
I like this text.
As a minor nit-pick, I'd change the MUST to a SHOULD if we're using
RFC-2119-style requirements keywords here, since i can imagine an
application developer talking here on the notmuch list and coming to
consensus in some particular use case that a given property should not
be project-specific. iow, they need to know *why* they're not following
the recommendation.
Thanks for writing this up!
--dkg
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2019-06-16 15:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-08 15:37 [PATCH] python: bind add_property/remove_property and related methods VA
2019-06-09 19:58 ` Daniel Kahn Gillmor
2019-06-10 12:55 ` VA
2019-06-11 9:31 ` Daniel Kahn Gillmor
2019-06-14 20:34 ` VA
2019-06-15 23:52 ` Daniel Kahn Gillmor [this message]
2019-06-17 4:31 ` Daniel Kahn Gillmor
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://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pnnecsob.fsf@fifthhorseman.net \
--to=dkg@fifthhorseman.net \
--cc=dev+notmuch@indigo.re \
--cc=notmuch@notmuchmail.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://yhetil.org/notmuch.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).