In an analogous process to the way clicking on some pikchr code

down
circle color red
text ""
text "Click me!"
text "Then select"
text "→ /pikchrshow"

Can then send the code to be viewed in the pikchr playground, wouldn't it be wonderful if some sqlite code

select 'obvious' as suggestion;

could be clicked on in order to open it in the sqlite fiddle.

Seems like a useful function for the forum, and I can't see any obvious attack vectors.

... could be clicked on in order to open it in the sqlite fiddle.

That's an interesting idea, and could be implemented the same way with (which uses your local JS's sessionStorage to store the the source code, then checks for that code when opening pikchrshow), but...

/pikchrshow is built in to fossil, so linking the forum to it is no problem. SQLite Fiddle is a standalone application on one particular site, so we don't want to link to it directly in fossil's code (we never link functionality with external sites). Even if we did link to that one, we'd need a way of submitting the data to it via POST (GET's size limit is too low), which would mean adding CGI-handling capabilities to sqlite3 own's shell (fiddle is essentially a customized build of that app¹). There's no chance of that latter part ever happening.

It would definitely be feasible to embed a copy of sqlite fiddle in fossil, but:

1. It can only read browser-side storage, so could not read the fossil database. Many repositories are too large to sensibly load into a browser session. Thus its general utility would be severely limited. (We explored ideas for using fossil with wasm early on in fiddle's development, but all useful ones, e.g. a more interactive timeline, run into the limit of having the full repo, or most of it, available in the browser. For example: just the blob hashes in Fossil's own repo are some 3.2mb.)

2. It would add roughly 1mb to fossil, just for the .wasm file (edit: 1.9mb for wasm+JS when compiled for minimal binary size). That's not a huge amount (edit: no, 1.9mb is huge) but the real utility for it in this particular context makes that cost unduly high. If it were 100kb, it might be more interesting.

1. ^{^} Search https://sqlite.org/src/file/src/shell.c.in for "fiddle"

a slightly simpler idea maybe?

• as there are interwiki prefixes manageable in fossil
• the markdown rendering code could try to generically match code classes to interwiki-prefixes (sqlite --> sqlite:, ) and generate these links (external, as configured in interwiki prefix)
• limited to GET and size limites there, but for short snippets probably large enough

Nowhere in the C-generated HTML do we ever refer to any server other than the fossil instance itself.

Thats why I was thinking about the interwiki prefixes: These are maintained by the user/admin and do link to external things already now if definied and used accordingly ...

We don't want to link any fossil functionality to a remote server, though.

Ah. That's probably a show stopper then. You could hide it behind an option and make the target fiddle instance configurable, but that suddenly becomes a lot of work™.

I retract my suggestion 😄

I came up with this idea while answering a forum question on the sqlite forum.

I wasn't really anticipating hosting the sqlite fiddle wasm directly in fossil.

I was more wondering if:

1. the sqlite fiddle CGI script (on sqlite.org itself) could accept SQL from a POST body.

2. pikchrshow style JavaScript sends the referenced code via post to the sqlite.org site and its own hosted version of "fiddle".

It appears that the first point is far more difficult than anticipated, which is fair enough.

I was probably fooled by the existence of the SQL examples in the dropdown menus - there clearly exists some method of replacing the default code already in place.

However the scaffolding to connect 2.) to 1.) is obviously the real feat, and if it is non-trivial then clearly not a worthwhile expenditure of time.

I would envisage this being primarily of use in the sqlite site forum, for code snippets posted as questions and solutions, rather than sending large databases through the fora.

the sqlite fiddle CGI script (on sqlite.org itself) could accept SQL from a POST body.

It's not a CGI - just a static web page. Yes, we "could" accept SQL via GET, but doing so would make me queasy.

As a static page, it cannot process POST data.

I was probably fooled by the existence of the SQL examples in the dropdown menus - there clearly exists some method of replacing the default code already in place.

Those are hard-coded into fiddle itself.

However the scaffolding to connect 2.) to 1.) is obviously the real feat, and if it is non-trivial then clearly not a worthwhile expenditure of time.

Right. It would be really cool for people to store stuff in fiddle and share links to it, but that requires server-side storage of the data so that it can associate links to queries (much like PasteBin and its ilk do). If it was open to anonymous usage it would eventually be filled by bots, so we'd need a way to manage users... the rat's tail of complication and maintenance is not something we want to take on.

I would envisage this being primarily of use in the sqlite site forum, for code snippets posted as questions and solutions, rather than sending large databases through the fora.

MB's suggestion of using an interwiki link in the sqlite forum would solve part of the problem of sharing links to pre-populated fiddle, but it won't work for more than trivial queries:

see [this query](fiddle:/?q=CREATE table t(a,b); insert into...)

Fossil's own markdown link parser would choke on that. Fossil cannot know whether parens should/must be balanced within that content so it parses only up to the closing paren of t(a,b), treating it as the closing for the hyperlink.

As a static page, it cannot process POST data.

Ah. And that was also a big misunderstanding on my part.

Thanks for clearing it up!

If you wished to do this, the answer would be for the forum, when desired, to wrap the sqlite.org/fiddle into an iframe and communicate with it using postMessage(), which is specifically designed for cross origin communication, and would allow the fiddle to remain a static webpage.

Note that the iframe embedding is optional - a handle can be captured by window.open(the fiddle page) too, and communication can be used like this instead.

This is almost indistinguishable from just linking to the fiddle.

// Open a new tab to the fiddle page from the forum post
const fiddleWindow = window.open("https://sqlite.org/fiddle", "_blank");

// Wait a short time (or use a different method of coordination)
setTimeout(() => {
  fiddleWindow.postMessage(
    { sql: "SELECT * FROM users;" },
    "https://sqlite.org"
  );
}, 500); // Or however long needed to load

Then on the fiddle page

window.addEventListener("message", (event) => {
  if (event.origin !== "https://fossil-scm.org") return;

  const sql = event.data.sql;
  if (typeof sql === "string") {
    editor.setValue(sql); // Replace with actual editor API
  }
});

To allow connections only from the fossil forum itself.

How big can the messages be? It's not clear, but certainly a few hundred kB. And you can send as many messages to the launched page as you wish.

This would have no effect on the actual server and the data would be processed locally. No sending the sql in a GET request. No server side logic to check the POST content.

The sql nippets would be "stored" in the forum, as they currently are.

It's a really good suggestion, actually.

window.open("https://sqlite.org/fiddle", "_blank");

This would be a non-starter. We won't embed dependencies on third-party tooling. A remote URL and the hypothetical postMessage API are both dependencies (and both technically third-party, from Fossil's perspective, despite sharing a project lead).

We would never be able to make any API changes on /fiddle's part, else we'd break that feature for every fossil version which predates that change. That's not an enviable situation to be in.

It's a really good suggestion, actually.

Patches would be thoughtfully considered,

the hypothetical postMessage API ... technically third-party

What's hypothetical or third-party about a first-party Web-Platform API?

And considering SQLite and its Fiddle, Fossil, and Pikchr as if completely independent also seems, well, strange.

I recently noticed the Pikchr click-to-toggle trick, and the suggestion to use it for SQL makes a lot of sense, FWIW.

What's hypothetical or third-party about a first-party Web-Platform API?

postMessage() is just the transport layer. An API to use via postMessage() would have to be designed to make fiddle "pluggable" by third-party software (like this forum). Designing, implementing, and maintaining that is not anywhere on our radar for fiddle.

It would be really cool to see someone else do it, though :). If we could take a couple of decades off of my age, i'd likely be able to find the energy to pursue such a thing as a side-project. Ah, to be young again!

And considering SQLite and its Fiddle, Fossil, and Pikchr as if completely independent also seems, well, strange.

They're three independent projects (along with their close siblings, althttpd, wapp, and probably a few more) and their public interfaces are developed as such. Fossil was the earliest test bed for 3rd-party integration of pikchr, but pikchr was never modified to suit in ways which are specifically "fossil-shaped."

I recently noticed the Pikchr click-to-toggle trick, and the suggestion to use it for SQL makes a lot of sense, FWIW.

It admittedly would, but requires per-data-type special-case handling. In the case of embedding fiddle, it would require a fair amount of new infrastructure and would add almost 2mb to fossil's delivery size (and would require downloading almost that much to you in order to run it).

...could be clicked on in order to open it in the sqlite fiddle.

It could be just as well copied into clipboard and pasted anywhere.

So maybe some Copy button may facilitate that.

It's a bit annoying to copy a long wall of SQL on mobile.

However, yes, that's a perfectly workable solution (and what a lot of people do now) and requires zero additional tooling.

Very reasonable to point it out, thank you.