Thanks @imwithye. It's a good idea. Not likely to happen in the short or medium term though, unless you happen to have skill in C++ programming (or are willing to learn). 😄

@imwithye Take a look at #1173 if you're specifically interested in JSON data visualisation. 😄

I was thinking about this enhancement. I believe the best approach for the user is to create an SQLite extension instead of one for ours. That would provide a function that converts the binary chunk to a textual decoding. Ideally the user should be able to choose this new function as a custom display format (see issue #573). But even with our current situation, the user would be able to create a view, which calls the function. Then the binary chunk can be visualized in the Text Cell Editor.

This approach would also work for image visualisations, if that is the kind of data that the display format function returns.

The trickier part of this approach is that if the user edits the textual representation and saves it back to the database, the binary chunk is overwritten with the new text data. This is already happening with multiple display formats, by the way, like the "Hex blob" one. This brings me to think, that what we need is being able to set a counterpart for the display format, that encodes the data back to its original form.

But if we only think in data visualisation, providing an SQLite extension as display format seems better to me, than developing our own visualisation extension framework.

... if the user edits the textual representation and saves it back to the database, the binary chunk is overwritten with the new text data. This is already happening with multiple display formats, by the way, like the "Hex blob" one.

Oh, that sounds like a bug. If someone edits a binary call in the hex mode and saves it back, it shouldn't be getting converted to a different data type. Well, not unless the new contents from the user really are a different data type. 😄

Quoting @justinclift from #1716 (comment)

Maybe we should start to think about a DB4S extension format that loads SQLite extensions, defines new custom display formats, based on the SQLite extension or not, defines function and help messages for syntax highlighter (for the new functions in the extension) and whatever that makes sense and comes to mind.

Yep, it's a decent idea. Wonder if it's something which could be cross platform?

Guessing it'll probably require compiled code, so whatever we figure out will likely include:

• Some kind of "metadata" (xml? or json?) which isn't OS-specific

• Loadable code (architecture specific)

  • .dll for Windows?
  • .dylib for macOS?
  • .so for *nix?

Wonder if it'll need to be compiled for a specific DB4S release? Probably yes, unless we can figure out some abstraction thing... then again I haven't done C++ code in years and barely remember it. This might be a mostly-solved problem already. smile

What I'm thinking could be solved simply by using an XML file. The only compiled part (in a platform specific shared library) would be an optional SQLite extension (like the math extension or the new PR #1716 one).The remaining options in the extension file are possible as data that we can load and use.

For example, our extension file for the math extension would do:

• Load the extension-functions dynamic library.
• Add these words as functions for the SQL syntax highlighter: acos, asin, atan, atn2, atan2, acosh, asinh, atanh, difference, degrees, radians, cos, sin, tan, cot, cosh, sinh, tanh, coth, exp, log, log10, power, sign, sqrt, square, ceil, floor, pi. String: replicate, charindex, leftstr, rightstr, ltrim, rtrim, trim, replace, reverse, proper, padl, padr, padc, strfilter. Aggregate: stdev, variance, mode, median, lower_quartile, upper_quartile.
• Add help messages for the so called Scintilla call tips for those functions.
• Add appropiate display format templates using some of those functions.

Sounds like a good approach, and a good use case for trying things out with. 😄