Log entries as struct, instead of an array

[TelegramSam]

Did Log Entries are currently arrays:
["4c99uuenu8gk6n3bgf09fuf350gx",1,"2024-04-15T19:56:18Z",{"method": ...

Why not a struct for clarity and future flexibility?

{
   "entryHash: "4c99uuenu8gk6n3bgf09fuf350gx",
   "versionID": 1,
   "etc": "etc"
}

shown multiline, but would be listed without whitespace in the .jsonl file.

This change would make future updates much easier, as the intention of the values is always known.

[brianorwhatever]

Our original thoughts on this were we want to set those fields in stone and any updates to the method would be in the parameters property. The repetition of these keys would add quite a bit more data size but this is definitely a possibility..

[swcurran]

I’m also thinking it doesn’t impact “future updates” too much, as the intention is that the version of the specification being used (the parameter method) for any entry in the processing dictates the exact meaning of each item. If the items in the array are changed in a future version of the spec (as we are already contemplating in #67), the meaning of each item is defined in the specification.

Or perhaps I’m wrong there. That answer means that the parameters location can NEVER change, since it is in the parameters that the method parameter is found, and a change to a new version of the specification would be found. A change to the method impacts the log entry currently being processed.

Options:

• move parameters permenantly to the first position in the array.
• move to the struct with named values.

[swcurran]

We've decide not do this at this time -- despite the fact that the parameters moved from item 4 to 3 in the array. :-)

Closing for this iteration of the spec.