As a user I want to be able to used automated classifiers to tag taggable things with appropriate tags I may have forgotten or not bothered to add so that I can be assured that a taggable item will show up under expected tags when I go looking for it.
Implementation Thoughts
YAML configuration file for external classifiers
Classifier must be able to take an url, or a path or both. It must print a valid JSON array of strings to Standard Out which BB would process and add as tags to the object.
URL would be the url of the thing (assuming a bookmark, or future taggable things with associated urls) PATH would be to the MD file of the archived item.
Classifiers would be invoked during an ExternalClassificationJob that would run after a bookmark has been archived.
I think if ArchiveUrlJob fails then it could check for classifiers that don't need PATH and kick it off for those.
I think at startup we initialize a bunch of ExternalClassifier objects in memory from the YAML. Maybe accessed via a Classifiers singleton? Which could have an .url_only and .path_only and .url_and_path methods which returned you an array (possibly empty) of classifiers that met the required criteria.
Maybe - for future proofing - any of them can also take the ID and OBJECT_TYPE (snake_case value like social_media_account) and then they can pass stuff back to the system via the API that doesn't exist yet. They'd need an API key which also doesn't exist yet.
foo-classifier:
name: "foo"
needs:
- URL
- PATH
executable
path: /path/to/foo
arguments:
- "--url"
- "{URL}"
- "{PATH}"
As a user I want to be able to used automated classifiers to tag taggable things with appropriate tags I may have forgotten or not bothered to add so that I can be assured that a taggable item will show up under expected tags when I go looking for it.
Implementation Thoughts
YAML configuration file for external classifiers
Classifier must be able to take an url, or a path or both. It must print a valid JSON array of strings to Standard Out which BB would process and add as tags to the object.
URL would be the url of the thing (assuming a bookmark, or future taggable things with associated urls) PATH would be to the MD file of the archived item.
Classifiers would be invoked during an ExternalClassificationJob that would run after a bookmark has been archived.
I think if ArchiveUrlJob fails then it could check for classifiers that don't need PATH and kick it off for those.
I think at startup we initialize a bunch of
ExternalClassifierobjects in memory from the YAML. Maybe accessed via aClassifierssingleton? Which could have an.url_onlyand.path_onlyand.url_and_pathmethods which returned you an array (possibly empty) of classifiers that met the required criteria.Maybe - for future proofing - any of them can also take the
IDandOBJECT_TYPE(snake_case value likesocial_media_account) and then they can pass stuff back to the system via the API that doesn't exist yet. They'd need an API key which also doesn't exist yet.