> I looked into this now and it seems to work but the issue is that even when using only one sequencer with -c MyUniqueName
> the page does not work anymore. We tried to create our own custom page for this now but maybe a nice addition would be to
> simply change the custom page to also support multiple sequencers.

The sequencer webpage does support multiple sequencers (and that's how it supports both the original sequencer and the python-
based sequencer). The choice of sequencer is based on the `SeqODB` URL parameter.

To create a link that will show up in the menu, create an entry in `/Alias` in the ODB.

e.g. for original sequencer:
odbedit -c "create string '/Alias/My new sequencer'"
odbedit -c "set '/Alias/My new sequencer' '?cmd=Sequencer&SeqODB=/SequencerMyUniqueName'"

e.g. for pysequencer:
odbedit -c "create string '/Alias/My new pysequencer'"
odbedit -c "set '/Alias/My new pysequencer' '?cmd=Sequencer&SeqODB=/PySequencerMyUniqueName'"

You can of course create this entry using the ODB web interface instead.

> > > > I was wondering if one can use multiple pysequencers at the same time and if not
> > > > if this feature is planned in the future? Our experiment (mu3e) has one frontend
> > > > per detector and each sequencer would only access a subset of ODB entries.
> > > 
> > > I believe sequencer design supports this, same as mlogger supports multiple output 
> > > files and mhttpd supports multiple listener ports.
> > > 
> > > But how to do this with pysequencer, I am not sure. Simplest is to wait a few more 
> > > weeks for Ben to return from vacation.
> > > 
> > > K.O.
> > 
> > I looked into this, and it has been possible for at least a year. Just start the sequencer with `-c MyUniqueName` and 
> > then all of the state etc. can be controlled from the ODB location `/PySequencerMyUniqueName/`.
> > And obviously use different names for each instance.
> 
> that's what I remember, too. but was not sure. K.O.

I looked into this now and it seems to work but the issue is that even when using only one sequencer with -c MyUniqueName
the page does not work anymore. We tried to create our own custom page for this now but maybe a nice addition would be to
simply change the custom page to also support multiple sequencers.

gitlab notifications do not send email on each commit and push (like bitbucket did).
to enable this, add your email address to the gitlab "emails on push integration": 
https://gitlab.triumf.ca/groups/midas/-/settings/integrations/emails_on_push/edit
K.O.

As for issue reporting, please use the gitlab work item tracker: https://gitlab.triumf.ca/groups/midas/-/work_items

You will need an account on the TRIUMF gitlab, but self-registration is enabled. If there are issues registering, please make a post here or send me an email. 

Note that we will not be monitoring issues on the bitbucket jira tracker. 

Thanks, 

Derek

Stefan uncovered a bug in mhttpd URI decoding, the following did not work:
cd midas, cd resources, cp example.html c++.html, open http://midas/example.html (works), open c++.html and it bombs with error about "c  .html" (two pluses replaced by two spaces).

Stefan did a quick fix for this and I now finished the follow up.

here are the rules for encoding URLs for mhttpd: (using this example URL)

https://experiment.triumf.ca/vslice/?cmd=ODB&odb_path=foo

the query parameter value "foo" should be percent-encoded using encodeURIComponent(). this replaces spaces with %20, slashes with %2F and pluses with %2B, etc. a plain bare plus character "+" is permitted here, it will seen as a space by mhttpd (odb_path=A+B becomes "A B").

the query parameter name "odb_path" should also be percent-encoded, but standard mhttpd parameters only use ascii character for parameter names and it is okey to skip encodeURIComponent() and hardcode them. if custom parameter names use special characters or other funny characters, they should be percent-encoded.

the elements of the URL path "vslice" should be percent-encoded if they contain special URI characters like "?" and "&". internally mhttpd runs the URL path through decodeURIComponent(). this expands all percent-encoded characters. (plus and space characters are not changed, URLs like c++.html work).

one exception for percent-encoded URLs is the percent-encoded slash ("%2F" instead  of "/"). for security reasons apache httpd and other web servers do not permit this. for consistency, mhttpd also rejects "%2F" in the URL path with the "404 Not Found" error.

TL&DR:

1) replaced old url-encode and decode functions with encodeURIComponent() and decodeURIComponent(). the mhttpd encoder is more aggressive compared to most javascript encoders (they leave characters like "_" and "(" unencoded). this is safe.

2) rewrote decode_query() to remove a strdup(), remove strtok() and manually parse the query string using bare URI query delimiters "&" and "=". malformed queries (mismatched "=" and "&") are silently truncated. in parameter values, plus is decoded as a space, decodeURIComponent() is consistently applied to parameter names and values.

3) added a trap in handle_http_message() against percent-encoded slash ("%2F" is rejected with "404 Not Found").

Commit 01336247eb4fa5bb6ed1a7187fa2061d6d4e9086
and 590d2b0812eacebd313efbe1c0c38a34f6eaf78f

K.O.

MIDAS Migration

We have transitioned from hosting MIDAS on bitbucket to TRIUMF's self-hosted gitlab instance (https://gitlab.triumf.ca/midas). Apologies for the early transition.

Do I need an account?

To push to the new server you will need an account on that server, and be added as a developer to the group. To create issues (or work items), you will also need an account. Otherwise, you can pull and clone anonymously.

Self-registration works on a whitelisting scheme: either your instiutional hostname or your full address needs to be whitelisted. If your regisration fails, please make a post in this forum or send me an email. 

How to get access to MIDAS?

You can pull to or push from the gitlab server. You can also pull from the bitbucket server - it has been set up as a mirror. Any changes to the gitlab repos will be pushed within 5 mins of the change. Long-term the bitbucket mirrors will be depreciated. 

Push permissions have been rescinded on bitbucket to enforce this.  

How to point your repos to the new server: 

git checkout develop
git pull --recurse-submodule
git remote set-url origin git@gitlab.triumf.ca:midas/midas.git # or use the html url: https://gitlab.triumf.ca/midas/midas.git
git submodule sync

Developer notes: 

Actions taken: 

• Removed write permissions from developer group to all MIDAS-related repos
• Transferred developers into a "Former Developers" group
• Re-synced gitlab and bitbucket repos
• Setup gitlab as push repos
  • This will expire Sep 25, 2027 (max duration)
  • Push mirroring happens after any push to the gitlab repo, with a minimum of 5 mins duration between mirror pushes
• MIDAS README updated

Thanks for reporting this. We need the 64 to keep the array size constant at n*64. The problem was the read of the v.c_str() beyond its length, 
which triggered the address sanitizer. I fixed that now and committed to develop.

Stefan

Hi,
I was seeing a crash when connecting remotely with MIDAS_SERVER_HOST. Debugging, it seems to be 
because hs_define_panel assumes all of its `var` are 64 bytes (at https://gitlab.triumf.ca/midas/midas/-
/blob/develop/src/history.cxx?ref_type=heads#L3507). But I'm passing in a shorter one. It doesn't happen 
when using a local Midas because the local path uses mstrlcpy which stops at the null terminator.

Is there a reason why it has to be 64 bytes? Or can I change it to the minimum of 64 and the string size? 
E.g.

-      db_set_data_index(hDB, hKeyVar, v.c_str(), 64, i, TID_STRING);
+      db_set_data_index(hDB, hKeyVar, v.c_str(), std::min(64, v.size()), i, TID_STRING);


Output from memory sanitiser is below.


==19362==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60400001d93a at pc 
0x5555556af004 bp 0x7ffffffc0d70 sp 0x7ffffffc0538
READ of size 64 at 0x60400001d93a thread T0
    #0 0x5555556af003 in __interceptor_memcpy 
(/build/online/switching_pc/midas_fe/switch_fe_central+0x15b003) (BuildId: 
069e8fae8f012afe15b42dd7e819397d7c530852)
    #1 0x55555593377c in rpc_call_encode(__va_list_tag (&) [1], RPC_LIST const&, NET_COMMAND**) 
/code/midas/src/midas.cxx:13612:13
    #2 0x55555591b412 in rpc_call(unsigned int, ...) /code/midas/src/midas.cxx:14295:7
    #3 0x555555969585 in db_set_data_index(int, int, void const*, int, int, unsigned int) 
/code/midas/src/odb.cxx:8249:14
    #4 0x555555a090a6 in hs_define_panel(char const*, char const*, 
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, 
std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >) 
/code/midas/src/history.cxx:3507:7
    #5 0x555555762c6c in setup_history() /code/online/switching_pc/midas_fe/switch_fe.cpp:454:5

> The history of at least bm.cxx seems to be screwed up. Bitbucket shows this:
>   https://bitbucket.org/tmidas/midas/annotate/fa649e6e9bb7447b4da01e964c6dc14b01e64052/src/bm.cxx?at=test%2Fsplit-midas-cxx
> and CLion shows what I attached here. Most lines are tagged "Today Olchanski" which cannot be.

yup, I see the same nonsense for bm.cxx from gitea.

back to the drawing board, will try branch, rename, merge as described here:
https://devblogs.microsoft.com/oldnewthing/20190916-00/?p=102892/

the naming of split files looks ok or we prefer more descriptive names "event_buffer.cxx",
"transition.cxx", "message.cxx", etc?

K.O.

The history of at least bm.cxx seems to be screwed up. Bitbucket shows this:

  https://bitbucket.org/tmidas/midas/annotate/fa649e6e9bb7447b4da01e964c6dc14b01e64052/src/bm.cxx?at=test%2Fsplit-midas-cxx

and CLion shows what I attached here. Most lines are tagged "Today Olchanski" which cannot be.

Best,
Stefan

> > A split of src/midas.cxx was discussed during Stefan & Thomas R. visit to TRIUMF.
> 
> A test of split src/midas.cxx is now pushed to branch test/split-midas-cxx
> 
> please take a look at this branch, run git log and git blame using your preferred tool of choice (vscode, clion, etc)
> and let me know if tracking of revision history works through the split commit and if there
> is any other oddities.
>

bitbucket web gui for src/rb.cxx
- show history - only to split commit (ouch!)
- show blame - all the way to the beginning of time (good)

K.O.

> A split of src/midas.cxx was discussed during Stefan & Thomas R. visit to TRIUMF.

A test of split src/midas.cxx is now pushed to branch test/split-midas-cxx

midas.cxx -> deleted, as required by git (see below)

cm_msg.cxx - will be all the cm_msg functions
bm.cxx     - all the event buffer functions
bk.cxx     - will be all the event bank functions
rb.cxx     - ring buffer functions (obsolete?)
rpc.cxx    - will be all the RPC functions
cm.cxx     - everything else

when I do the split for real, I think I will split run transitions to cm_transition.cxx

please take a look at this branch, run git log and git blame using your preferred tool of choice (vscode, clion, etc)
and let me know if tracking of revision history works through the split commit and if there
is any other oddities.

also, better names for the split files are most welcome.

only rb.cxx and bm.cxx are actually reduced in size, the rest of the files are still copies of midas.cxx (this is only a test of the 
split).

K.O.

P.S. More details below:

> 
> Main reason for the split is to simplify analysis using AI tools, they work best on smaller files that contain closely related 
> code.
> 
> Main difficulty with the split is "git" tooling, which does not have a concept of file copy or file split. (still this is better 
> than older tools like cvd and svn, which had no concept of branching and merging).
> 
> My first step is to do a strawman split of midas.cxx on a branch, push it out and ask people to check that they git tooling 
> (vscode, clion, bitbucket, github, gitea, etc) see the split correctly.
> 
> Ideally, git log and git blame should be able to trace the revision of each split file
> back to the beginning of time, instead of to the point of split from midas.cxx.
> 
> According to google AI, I should do this:
> 
> step 1: midas.cxx removed, split files are exact copies of midas.cxx, this allows git to identify the split point
> 
> cp midas.cxx split1.cxx
> cp midas.cxx split2.cxx
> ...
> git rm midas.cxx
> git commit
> 
> step 2: edit the split files to remove duplicated code, commit.
> 
> step 3: check
> 
> git blame split1.cxx -> shows correct revision history for me. maybe need to use "-C"
> git log split1.cxx -> shows correct revision history to split commit
> git log --follow split1.cxx -> shows correct revision history for me
> 
> TD;DR continue below.
> 
> Identify all function names in midas.cxx:
> 
> cat midas.cxx | grep -v -e "^ " -e "^{" -e "^}" -e "^$" -e "^/" -e '^\\' -e "^@" -e "^*" -e "^#" | sort
> 
> ^void functions:
> 
> void bk_xxx()
> void bm_xxx()
> void cm_xxx()
> void dbg_xxx()
> void rpc_xxx()
> 
> ^std::string functions:
> 
> cm_xxx()
> msprintf()
> rpc_xxx()
> 
> ^static functions:
> 
> bm_xxx
> rpc_xxx
> cm_xxx
> 
> ^int functions:
> 
> bk_xxx
> bm_xxx
> cm_xxx
> cm_msg_xxx
> rb_xxx
> rpc_xxx
> 
> ^const data
> 
> cm_xxx
> rpc_xxx
> 
> ^bool functions:
> 
> rpc_xxx
> 
> ^INT functions
> 
> bk_xxx
> bm_xxx
> cm_xxx
> cm_msg_xxx
> rpc_xxx
> 
> ^BOOL functions
> 
> bk_xxx
> cm_xxx
> 
> LC_ALL=C sort midas.cxx | grep -v -e "^/" -e "^\s" -e "^W" -e "^w" -e ^} -e ^{ -e ^[a-v] -e '^\\' -e ^[A-U] -e ^@ -e ^* -e ^# -e ^$
> 
> Stawman split:
> 
> midas.cxx -> deleted
> 
> cm_msg.cxx - all the cm_msg functions
> bm.cxx     - all the event buffer functions
> bk.cxx     - all the event bank functions
> rb.cxx     - ring buffer functions (obsolete?)
> rpc.cxx    - all the RPC functions
> 
> cm.cxx     - everything else
> 
> K.O.

A split of src/midas.cxx was discussed during Stefan & Thomas R. visit to TRIUMF.

Main reason for the split is to simplify analysis using AI tools, they work best on smaller files that contain closely related 
code.

Main difficulty with the split is "git" tooling, which does not have a concept of file copy or file split. (still this is better 
than older tools like cvd and svn, which had no concept of branching and merging).

My first step is to do a strawman split of midas.cxx on a branch, push it out and ask people to check that they git tooling 
(vscode, clion, bitbucket, github, gitea, etc) see the split correctly.

Ideally, git log and git blame should be able to trace the revision of each split file
back to the beginning of time, instead of to the point of split from midas.cxx.

According to google AI, I should do this:

step 1: midas.cxx removed, split files are exact copies of midas.cxx, this allows git to identify the split point

cp midas.cxx split1.cxx
cp midas.cxx split2.cxx
...
git rm midas.cxx
git commit

step 2: edit the split files to remove duplicated code, commit.

step 3: check

git blame split1.cxx -> shows correct revision history for me. maybe need to use "-C"
git log split1.cxx -> shows correct revision history to split commit
git log --follow split1.cxx -> shows correct revision history for me

TD;DR continue below.

Identify all function names in midas.cxx:

cat midas.cxx | grep -v -e "^ " -e "^{" -e "^}" -e "^$" -e "^/" -e '^\\' -e "^@" -e "^*" -e "^#" | sort

^void functions:

void bk_xxx()
void bm_xxx()
void cm_xxx()
void dbg_xxx()
void rpc_xxx()

^std::string functions:

cm_xxx()
msprintf()
rpc_xxx()

^static functions:

bm_xxx
rpc_xxx
cm_xxx

^int functions:

bk_xxx
bm_xxx
cm_xxx
cm_msg_xxx
rb_xxx
rpc_xxx

^const data

cm_xxx
rpc_xxx

^bool functions:

rpc_xxx

^INT functions

bk_xxx
bm_xxx
cm_xxx
cm_msg_xxx
rpc_xxx

^BOOL functions

bk_xxx
cm_xxx

LC_ALL=C sort midas.cxx | grep -v -e "^/" -e "^\s" -e "^W" -e "^w" -e ^} -e ^{ -e ^[a-v] -e '^\\' -e ^[A-U] -e ^@ -e ^* -e ^# -e ^$

Stawman split:

midas.cxx -> deleted

cm_msg.cxx - all the cm_msg functions
bm.cxx     - all the event buffer functions
bk.cxx     - all the event bank functions
rb.cxx     - ring buffer functions (obsolete?)
rpc.cxx    - all the RPC functions

cm.cxx     - everything else

K.O.

Dear MIDAS Community,

In a little over a week from today, on September 28, we will migrate the MIDAS repository away from bitbucket and to TRIUMF's self-hosted gitlab instance.

What does this mean for you?

Developers: If you want to push changes to the repository, you will need reconfigure your git settings to point to the new host. You will also need accounts on TRIUMF's gitlab (self-registration open).

Users: The bitbucket instance will remain as a mirror so everyone doesn't have to change every experiment. You will still be able to pull from bitbucket to fetch the latest updates. You may need to re-sync your submodules to have everything point to the right host. 

Full migration instructions will be provided here, at this forum, on September 28. 

Thanks, 

Derek

some cleanup of mhttpd:
- remove obsolete c-generated equipment view page (replaced by eqtable.html)
- remove support for obsolete versions of mongoose (HAVE_MONGOOSE4, HAVE_MONGOOSE6, mhttpd6)
- remove support for https, openssl and mbedtls

support for https may return after we upgrade to a current version of mongoose (latest is 7.23, we have 6.16).

support for user passwords in mhttpd I leave alone for now,
but their security is limited:
a) lacking https, passwords are transmitted in clear text, this is only safe
   for localhost connections) and
b) mhttpd always used the unusual http digest authentication,
   which is no longer recommended because of:
b1) weak/insecure server-side password storage and
b2) weak security of the digest authentication token itself

for secure use of MIDAS, we recommend placing it behind a password protected https proxy (i.e. apache httpd)

K.O.

we have one computer that crashes regularly and produces a corrupted ODB. while 
debugging it, I discovered that for some ODB corruptions and for some unexpected 
ODB errors, the ODB JSON encoder will produce invalid JSON files that cannot be 
reloaded, and also produce zero-size JSON files without any explicit error 
message.

these problems are now corrected, odbedit save odb.json will now always
produce valid JSON (ODB errors are encoded as JSON "null"), and always
write the encoded JSON data to odb.json, even if there were encoding errors.

to remember, the JSON encoder I originally wrote in C (before MIDAS wholesale 
switch to C++). The JSON parser (mjson.h, mjson.cxx) and the JSON ODB decoder 
(json_paste.cxx) I originally wrote in pre-C++11 C++ (odb.c was still in C
at the time, this is why json_paste.cxx is a separate file). all of them
are now updated to C++11.

merge commit 8a4c52da22f67ba7cbfc7d98a0fc81eeccdc7111

K.O.

My update of db_get_data_vec() got delayed because I had to figure out
how the links to array elements work and fix a number of places
where they are not handled correctly or consistently.

Current status after the db_get_data_vec() merge:

1) db_get_data(), db_get_data_vec(): links to array elements work
2) db_get_value(), db_get_data_index(), db_get_data_index(): not implemented, will return a type mismatch
3) mhttpd obsolete "jcopy": works correctly now (previously produced invalid json)
4) odbedit save odb.json: works correctly now (prevously produced invalid json)

I think for consistency, I should implement links to array elements in db_get_value(), db_get_value_string() and db_get_value_vec().

K.O.

> this is a draft message, it will be updated with additional information. K.O.
> 
> Back in 2007, Stefan implemented the very useful feature, ODB links to array elements,
> https://daq00.triumf.ca/elog-midas/Midas/418
> 
> This is handy for "Edit On Start", for history links, for feepics and other places.
> 
> If you have an array in ODB: 
> 
> ia5                             INT32   5     4     12m  0  RWD   
>                                         [0]             10
>                                         [1]             11
>                                         [2]             12
>                                         [3]             13
>                                         [4]             14
> 
> a normal ODB link works as a UNIX filesystem symlink, whereas an ODB link that includes an array index refers to just one element of the link target array:
> 
> symlink_to_ia5_2 -> /test_odb/ia5[2]
>                                 INT32   1     4     12m  0  RWD   12
> 
> Because there was some confusion over how it works and how it is actually implements,
> some ODB functions do not implement this feature consistently.
> 
> Here, I explain how it actually works:
> 
> 0) expected syntax is: "link name" -> "/link/target/array[12345]":
> 
> - "/link/target/array" is the absolute ODB path to the link target (must start with "/", relative links are not permitted)
> - array index "12345" should be an integer (converted using atoi())
> - there should be nothing after final "]"
> - there should be nothing between the "[" and the array index decimal numeric value
> 
> 1) db_get_data():
> 
> - before calling db_get_data() we must call db_find_key()
> - db_find_key() will resolve ODB links and return the final destination (or an error if dangling link or circular link or too many nested links)
> - db_get_data() will return the data from this ODB key. this is the path for normal symlinks.
> 
> - if db_find_key() encounters an ODB link to an array element (target path contains "["), it returns this key (of type TID_LINK).
> - db_get_data() checks the key type (normally it would be TID_INT, TID_STRING, etc). if it is TID_LINK, it means we have a link to an array index (as identified by db_find_key())
> - in this case, ODB link is resolved using db_find_key(), array index is extracted from the link
> - and db_get_data() returns data for the corresponding array element
> 
> If db_get_data() is called using an hKey returned by db_find_link() (instead of db_find_key())
> and it happens to be an ODB link (TID_LINK), we have an inconsistent result:
> 
> - if it's a normal link, db_get_data() will return a type mismatch error
> - db_get_data(TID_LINK) will return the link target string (NUL-terminated)
> - if it's a link to an array element, db_get_data() will resolve it and return data from the link target array element.
> - db_get_data(TID_LINK) will return a type mismatch error because it will resolve the link, then fail the type check as link target cannot be TID_LINK
> 
> 2) db_get_value(), db_get_data_index()
> 
> - normal links work, resolved by db_find_key()
> - links to array elements not implemented, will return a type mismatch error (i.e. TID_LINK vs user requested TID_STRING, TID_INT, etc)
> 
> 3) mhttpd obsolete "jcopy"
> 
> - broken, returns malformed json (old code), returns the complete array, not just the linked array element (new code)
> 
> 4) odbedit save odb.json
> 
> - broken, output file odb.json is empty (new code)
> 
> K.O.

The MIDAS RPC layer can pass std::string and std::vector data of arbitrary size.

I am adding corresponding ODB API functions to use this. Instead of taking a pointer to preallocated array 
(and we must know the size ahead of time, i.e. by reading the ODB key), we pass a pointer to an 
std::vector<char>, all memory allocation is taken care of by the RPC layer.

INT EXPRT db_get_data_vec(HNDLE hdb, HNDLE key_handle, std::vector<char> *data, DWORD type);
INT EXPRT db_get_data_index_vec(HNDLE hdb, HNDLE hKey, std::vector<char> *data, INT index, DWORD type);

This helps with programming MIDAS "the c++ way" and fixes subtle errors like the memory leak
in the odbxx code if an exception is thrown - free(buffer) is never reached.

         //int size = rpc_tid_size(m_tid) * m_num_values;
         //void *buffer = malloc(size);
         //void *p = buffer;
         std::vector<char> odbdata;
         status = db_get_data_vec(s_hDB, m_hKey, &odbdata, m_tid);
         void *p = odbdata.data();
         for (int i = 0; i < m_num_values; i++) {
            if (m_tid == TID_UINT8 || m_tid == TID_CHAR)
               m_data[i].set(*static_cast<uint8_t *>(p));
            else
               mthrow("Invalid type ID " + std::to_string(m_tid));
         }
         //free(buffer);

next to add is db_get_value_vec(). we already have a db_get_value_string().

K.O.

> There was a bit of confusion on the MIDAS Programs page with programs that have 
> similar names. This confusion relates to the use of bUnique in cm_shutdown() and 
> cm_exist().

Final disposition:

1) cm_shutdown() takes the exact client name, no confusion leading to shutdown of wrong frontend.

2) cm_exist() takes the exact client name if bClientName is true, or the exact program name if bClientName is false.

cm_exist() with a program name is used by the alarm code to check the "program not running" alarms:

for example, "odbedit is not running" should fire only if all clients with program name "odbedit" are
not running. actual client names (if many odbedit are present) would be "odbedit", "odbedit1", "odbedit2", etc,
and they all have the same program name "odbedit".

program name is a new thing, stored in ODB /System/Clients/pid/Program next to the client name (pid/Name).

3) the "stop program" button on the MIDAS Programs page has a list of all MIDAS clients, loops over them
and shuts down all clients with matching program name.

K.O.

A major update of the ODB Browser has been made in the last few days. Here are the new features:

• The browser supports now multiple tabs. You can open as many tabs as you like, and they stay persistent even if you navigate away and come back to the ODB page (unless you close the browser). This allows easily swiching between different subdirectories in the ODB.
• A "Live Indicator" on the top right corner indicates live updates from the ODB and an error should the current ODB values not be updated any more.
• A new "Duplicate" button lets you duplicate the current subdirectory. This can become handy if you want to clone an alarm for example.
• A new Speed Selector lets you select ODB keys with the keyboard. Simply type the first few letters of a key and the selection will  jump there. If it's a subdirectory and you press <enter>, you will traverse into that subdirectory. If it's a normal key, you will enter the edit mode for that key. The <backspace> key navigates up the hierarchy (parent direcotry). This way you can navigate and modify the ODB easily without using the mouse. Use cursor keys to navigate up and down. The full keyboard shortcuts help is available under ... -> Help... and attached below.
• Loading or importing or pasting keys into the ODB brings up the preview dialog. Here one can select which values actually go into the ODB. Subdirecories can be selected or unselected as a whole or via their individual keys. For arrays, one can select the whole array or individual array elements.

The attachments below show some of the new elements and how they can be used. Changes are committed to the develop branch of MIDAS.

Feedback welcome.

Stefan