The HUDoc project was invented to overcome phychological barrier of additional actions required to write and maintain documentation.

It is based on system of aliases that notify HUD server about context the user is in. A HUDOC window would then allow on-the-spot editing of documentation associated with the context.

Context might be any activity the user is doing at the moment. It might be defined by .hudoc.yaml file in the directory (or upper-level directories) the user is in. Later on we can use other means to identify the activity (screen OCR, HUDOC-aware apps/breadcrumbs, inotify on files being opened, etc).

The “context switch” then causes associated documentation to show up in HUDOC window, enabling user to view or edit it.

• Get into directory of a server: ``CHDIR|hungama-ingestion:/opt/tmp_14days``
• ssh into a server: ``SERVER:bas1``
• execute a command: ``CMD:dap2:/opt/mysql_reports_sdemo:dcmy``

At POC stage, (when there is no HUDOC window yet) type “dh” command see contexts (if any) for the current host or directory or command (“dh [command]”).

Piece of documentation for a context is called “F1memo”.

Initially F1memos are stored in the wiki, as stepping stone on a path to full-fledged F1memo store. Backend dokuwiki engine provides important out-of-the-box capabilities, such as authentication, using browser to edit F1memo, builtin markup language, search.

F1memo reference is also called F1context or simply context. It has format “COMPANY:Level1,Level2…”, case insensitive.

Examples of F1memo pieces:

• SERVER [bas1]
• SERVER [k8cc]
• gmc

During POC, frontend is JS-enabled website window that user can switch to easily (F1 button comes to mind). It has functions below:

• Authenticate users
• Receive updates from Backend about context switches
• Open wiki page for given context in iframe

Backend receives context switches from “agents” and sends them to corresponding Frontend session.

Ideas on Frontend improvement

HUD backend must be aware about context switches of many users so to send appropriate messages to HUD frontend. For ssh sessions and commands we employ scheme below:

1. User does ssh into master using his username. Script .bashrc defines HUDOC_USER_ID environment variable
2. ssh command is actually alias that sens environment variable LC_F1USER along, like this:

   export LC_F1USER=skliarie@gmail.com; ssh root@bas1.catchmedia.com -o SendEnv=LC_F1USER

3. The environment variable becomes visible on the target server, thanks to allowance in sshd_config for all LC_* vars:

   root@bas1:~# grep LC_ /etc/ssh/sshd_config
   AcceptEnv LANG LC_*

4. .bashrc script creates /tmp/f1daemon/tmp/PID file with content of $LC_F1USER. F1daemon watches the directory (using inotify) on tries to figure out the context, using /proc/$$/cwd symlink, pstree and other heuristics.
5. Successfully recognized context switches are sent to backend (using redis-ops pubsub for now)

There might be browser add-on, that will detect newly opened URLs and report them to HUDoc server for analysis and possible context matching.

The feature is for startup-stage. A native desktop agent identifies contexts in native apps based on various heuristics and reports them to HUDoc server for analysis and possible context matching.