Local storage

julienbidoret commented

2024-10-02 10:19:42 +00:00

(Migrated from gitlab.com)

An hypothesis to use stolon as a guest, without credentials, would be to use local storage.

When not logged in and trying to save, when the login form pops up, a “continue as guest” would appear.
It would trigger a popup / alert to warn that local storage will be used (persistence is only guaranteed until browser data is wiped out).

We could then inject the local stems at the start of the stems gallery, marking them with a special border / ribbon.

An hypothesis to use stolon as a guest, without credentials, would be to use local storage. When not logged in and trying to save, when the login form pops up, a “continue as guest” would appear. It would trigger a popup / alert to warn that local storage will be used (persistence is only guaranteed until browser data is wiped out). We could then inject the local stems at the start of the stems gallery, marking them with a special border / ribbon.

julienbidoret commented

2024-10-02 10:23:21 +00:00

(Migrated from gitlab.com)

mentioned in issue #28

raphaelbastide commented

2024-10-02 10:45:00 +00:00

(Migrated from gitlab.com)

That is an excellent idea!

julienbidoret commented

2025-01-04 13:59:09 +00:00

(Migrated from gitlab.com)

Some quick notes, thrown here:

“localSave mode” might be active until a login action is performed: localStorage should keep a list of local stems → until a login occurs. Then, each Save action on a local stem should remove it from the localStemsList and localStorage and save it to server
how do we take potential name conflicts into account ?
deal with local stem renaming

Some quick notes, thrown here: - “localSave mode” might be active until a login action is performed: localStorage should keep a list of local stems → until a login occurs. Then, each Save action on a local stem should remove it from the localStemsList and localStorage and save it to server - how do we take potential name conflicts into account ? - deal with local stem renaming

julienbidoret commented

2025-01-04 14:50:20 +00:00

(Migrated from gitlab.com)

Ow…
This moment when you realize your idea was broken at start: some HTML, JS and CSS files are needed for the iframe! But we can’t create files locally (storing data is easy, but not creating files).
Pfu.. I fear the only option for “guests stems” would be a server-side option.

Ow… This moment when you realize your idea was broken at start: some HTML, JS and CSS files are needed for the iframe! But we can’t create files locally (storing data is easy, but not creating files). Pfu.. I fear the only option for “guests stems” would be a server-side option.

raphaelbastide commented

2025-01-04 15:22:39 +00:00

(Migrated from gitlab.com)

Yes true, unfortunately. We could store stems’ JSON to local storage but that would mean rewrite the entire folder-dependent PHP code just for that case. It doesn’t worth it. Plus, I wonder if this guest option is really needed, maybe on your side? But not on mine, at least for now.

julienbidoret commented

2025-01-04 15:27:34 +00:00

(Migrated from gitlab.com)

I wanted to allow the local forking of stems by students, without giving full access and polluting the global gallery. But indeed, that would require a massive change in how stems are stored on the server (without even mentioning some security issues we don’t want to deal with!)? Definitely not worth it…

julienbidoret commented

2025-01-04 16:08:02 +00:00

(Migrated from gitlab.com)

I was about to close the issue when I encountered https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/srcdoc ;)

raphaelbastide commented

2025-01-04 16:22:48 +00:00

(Migrated from gitlab.com)

Oh. That could be interesting, also maybe to optimize the saving, that is sometimes a bit laggy.

Rows
Columns

Local storage #29