[PATCH] python: bind add_property/remove_property and related methods

[Daniel Kahn Gillmor]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20190616/9cd518b8/attachment.sig>