JoeOsborn
commented
5 months ago OK here's the idea.
Two new tables in the schema: groups and galleries. A group is a collection (for a single instance) of states and replays. A gallery is a collection of states/replays/groups, each with a text label and markdown/rich text description, that we can render as a simple form of document.
When you load a state or a replay into the workbench, it's got a special place outside of any group. All other states and replays go into a group, which will be on the local filesystem. You can also pull/download an existing group without leaving the state/replay you're workbenching, and it will be on your local filesystem. Every state or replay that gets saved goes into the current group, and you have a little dropdown or some other UI to move it into another local group, or delete it. Local groups persist across all uses of gisst. When you want, you can upload a group (it will go into a groups table with primary key (group_id,group_version)). You can fork someone else's group by uploading it yourself and it will get a new ID (in the future, groups will have an owners list and multiple people can add and remove from a group). A group page will let owners add and remove stuff from that group. There's a button to delete a group and remove its states (locally).
You can also cite/load a group directly into the workbench, so there is no initial state/replay but you have that group ready to go.
In the short term groups can be implemented as a purely local concept, and in the future they will be uploadable to the server and reinforced with galleries. It'll be awesome.
ekaltman
It might be nice to have a persistent workspace in the frontends, per-instance, which can easily be cleared for that instance (or maybe multiple stored "projects" per instance?)