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
Description: PGP signature
_______________________________________________ notmuch mailing list firstname.lastname@example.org https://notmuchmail.org/mailman/listinfo/notmuch