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

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

Besides serving as F1memos storage, the wiki contains other information pieces. The only way to find them is using search by keywords. So please think carefully about which keywords the next guy is going to use to find your page.

You can start by reading list of existing page names.

Context tag is string that uniquely defines activity the user is doing at the moment. It might be server/path the user is currently in. Later on we can use other means to identify the activity (screen OCR, F1x-aware apps/breadcrumbs, inotify on files being opened, etc).

The “context switch” then causes associated documentation to show up in F1x help 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``

Piece of documentation for a context is called “F1x memo”.

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

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

During POC, frontend is JS-enabled website window that user can switch to easily (for example using F1 button). 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

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

1. User does ssh into master using his username. Script .bashrc defines LC_F1USER 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/f1x/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 F1x 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 F1x server for analysis and possible context matching.