CSPro embedded cpp-httplib server: minimum configuration
Posted: May 12th, 2023, 12:46 am
Dear CSPro Developer Team
I already asked a minimum control over the cpp-httplib CSPro embedded server.
1) CSProusers need to access to it via a defined external local IP (not randomly as it is right now and only the default locahost 127.0.0.1);
Why?
Among others, It will be easier for devices to share data over a WIFI/wired LAN with simple HTTP post, put and get.
2) CSProusers would like to put following header on the CSPro embedded server:
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Why?
a) Better use of service worker and worker thread in the future.
Is this something we need in a CSPro app?Definitly yes! I faced situations where we need them in the 7.7 version. For example I used CSPro-JS API to display some HTML-CSS/JS UIs via HTML dialog. But, when I call an async function to display a CSPro UI, the HTML-CSS/JS UI still persists. And sometimes, I have several HTML/JS pages opened at the same time... It's because closing a HTML-CSS/JS window doesn't send any message easily accessible to CSPro logic... Thanks to Greg for offering us a way to solve this in the next cut: viewtopic.php?t=5338
b) Running most wasm libs also requiring it. As a primary example, persistent storage WASM SQLite : https://github.com/tomayac/sqlite-wasm
Why having SQLite WASM if we already have CSDB?
As an example, offline mapping with Leaflet. In his last release, CSPro map have some limitations. If not overcome in the next cut,
it will be possible for CSProusers to use a single map engine, Leaflet on both OS, Windows and Android, and among others, supporting offline tiles.
Other examples:
a) automatic data replication between CSDB and a persistent OPFS sqlite-wasm.
b) Automatic silent sync;
c) Sync and writecase data directly inside the main dictionary
d) Etc.
Thanks in advance
I already asked a minimum control over the cpp-httplib CSPro embedded server.
1) CSProusers need to access to it via a defined external local IP (not randomly as it is right now and only the default locahost 127.0.0.1);
Why?
Among others, It will be easier for devices to share data over a WIFI/wired LAN with simple HTTP post, put and get.
2) CSProusers would like to put following header on the CSPro embedded server:
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Why?
a) Better use of service worker and worker thread in the future.
Is this something we need in a CSPro app?Definitly yes! I faced situations where we need them in the 7.7 version. For example I used CSPro-JS API to display some HTML-CSS/JS UIs via HTML dialog. But, when I call an async function to display a CSPro UI, the HTML-CSS/JS UI still persists. And sometimes, I have several HTML/JS pages opened at the same time... It's because closing a HTML-CSS/JS window doesn't send any message easily accessible to CSPro logic... Thanks to Greg for offering us a way to solve this in the next cut: viewtopic.php?t=5338
b) Running most wasm libs also requiring it. As a primary example, persistent storage WASM SQLite : https://github.com/tomayac/sqlite-wasm
Why having SQLite WASM if we already have CSDB?
As an example, offline mapping with Leaflet. In his last release, CSPro map have some limitations. If not overcome in the next cut,
it will be possible for CSProusers to use a single map engine, Leaflet on both OS, Windows and Android, and among others, supporting offline tiles.
Other examples:
a) automatic data replication between CSDB and a persistent OPFS sqlite-wasm.
b) Automatic silent sync;
c) Sync and writecase data directly inside the main dictionary
d) Etc.
Thanks in advance