Skip to content

Future Work

Please share your thoughts and, even better, contribute ;)

Note: Some of these ideas are captured as issues at https://github.com/mbari-org/docs-mbari-org-webhook-doc/issues.

GitLab

Probably, also support GitLab:

Branches

Only pushes to the default branch (as determined upon initial clone, typically "main" or "master") trigger the generation process. A possible TODO is to also allow the processing for other branches, which, for example, would be convenient if people are to contribute content via pull requests and the maintainers would like to review the resulting site in a separate location (named after the branch) before merging the PR.

Hierarchical organization

As the number of hosted sites grow, we may need to look into also supporting a hierarchical organization, say, by some form of "project," "workspace," ...

In a similar fashion as with Google Docs, we should probably consider adding this form of special visibility. It could be along the lines of the following:

  • Designate one other path, say /-/, under which AWTL sites are deployed.

  • An AWTL site's target directory must be a UUID (or some other, maybe shorter, but unique and unguessable ID). Example: http://docs.mbari.org/-/3137056b-600c-4b3c-bc78-25bf52147ce6.

  • When opting for this option, the user will indicate in .mbaridocs.json:

    {
  "visibility": "awtl",
  "destination": "3137056b-600c-4b3c-bc78-25bf52147ce6"
}

    that is, the ID is to be provided by the user.

  • Sites under /-/ are of course not to be listed/indexed publicly. So, appropriate mechanisms should be put in place (e.g., robots meta tag, robots.txt, ...) for search engines not to index them either.