Idea

+status

open

+priority

medium

+tag

+issues

In pursuit of DeckoSystems and beyond, this is a first step.

Need to support more than one deck in one or more ways:

Support multiple independent small Decko instances in one Database and web app instance.
Support serving and rendering cards and card nests from more than one Deck.
- Use for one or more (read only) Decks for core and modular types, sets and rules. Have much smaller private Decks for private Cards and data.
- Use for card-mods and other Card based networked content. Use DeckoSystems protocols to update and cache networked contend in local database (cards db with distinct deck ID).
Multideck namespace integration (DeckoSystems+names)

+solution

First goal is the minimal viable to do the first bullet point. The plan is to handle name based virtual hosts mapped to subset of card_id as grouped by new column to cards deck_id. All id links should initially be partitioned by deck_id, meaning that left, right and type ids as well as same in references and history will all be same deck_id value.

A deck_id will be one-to-one with a website (hostname).

I'm thining that maybe next steps are to add an option to some of the decko commands to select a deck. Then I could seed a second one and run tests in the default or additional instances.

A test with only deck_id:10 populated with test seeds, but no seeds for default (1) should be a pretty good test. Then some routing tests for the name based routing to select a given deck.

I'll have to investigate how to use cucumbers where hostnames are 'routed'. Should be doable.

+discussed in support tickets

+relevant user stories