[PATCH] python: bind add_property/remove_property and related methods
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Sat Jun 15 16:52:52 PDT 2019
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
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
Thanks for writing this up!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 227 bytes
Desc: not available
More information about the notmuch