DeckoSystems
+overview
Wagn 1.0 was an app. Decko 1.0 is a framework for building apps that we call "decks". Decko 2.0 will be a network of decks.
DeckoSystems is the umbrella term for all interdeck networking.
+needs
Card sharks often find themselves wanting to integrate content across multiple decks. A few examples:
- Help text shared across multiple structurally similar sites
- A shared public glossary or ontology
- A base dataset to which multiple decks are adding metadata
For these cases and others we need ways of linking, nesting, querying, and otherwise connecting cards across decks.
+solution
DeckoSystem integrations will share common patterns:
- URI's for remote decks
- card identifiers (marks) for remote cards
- local read-only caches of type/content
The simplest integration is a single card mapping. This could be implemented quickly; the content can dictate both the uri and the remote card identifier. The local name need not match the remote name. In fact, this functionality could be used for many kinds of non-Decko content.
More compelling still is the capacity to connect many cards at once. But doing so without namespace conflicts can be challenging, particularly since the remote deck will need to reserve the right to add cards without looking for conflicts in any and all decks that use its cards.
Therefore the primary conceptual need for deep DeckoSystem integration is namespace support. At present all Decko names are in a root namespace; there must be others. Here's one proposal for how that might work.
+names
Proposals for improvements to card name handling.
Joints
Joints in Context
Decks (Namespaces)
Contexts within decks
Quick aside: there is admittedly some potential for confusion with the term deck, now commonly used to refer to decko sites, and the new namespace meaning, which would imply part of a decko site. On the other hand, the fractal pattern of decks within decks is very Decko. Within this document, when disambiguation is needed we will use "site decks" to refer to the umbrella deck and "deck cards" to mean the narrower namespaces.
- Home would refer to mysite.com/mydecko/mydeck/mycard/Home (current card context)
- /Home would refer to mysite.com/mydecko/mydeck/Home (root of current namespace)
- //Home would refer to mysite.com/mydecko/Home (root of site deck)
- ///Home would refer to mysite.com/Home (root of host)
Mounting remote decks
- a URI for the source deck
- scoping information delineating the cards to be mounted
- authentication information in cases where the remote deck can be updated from the local deck
There will likely also need to be additional configuration, for example to specify policies regarding synchronization, local overrides, etc.
Given the framing above, it is quite conceivable that a MountDeck will refer to cards outside of the local context, either because the reference goes beyond the delineated scope or because the remote deck refers to something outside of its namespace as mentioned above. Such cards should be treated as a special category of "unknown" which may be given special views.
For example, imagine a local deck local that mounts a foreign deck remote/D at local/M. That would be, for example, that remote/D/A would be available at local/M/A. But suppose that remote/D/A card refers to something outside of its namespace, like remote/X; local/M/A doesn not have access to that card. (We're not specifying a solution here, only noting that the system needs to be robust in the face of such references).
Rules within decks
Furthermore, what if we wanted to override a given rule on /B+*right in /X. Could we do that at /X/B+*right? If so, we are potentially in some cases adding yet another dimension (namespace) to inheritance patterns that can get quite complex on Decko, where formats and sets and (in the case of preferences) users can intersect in complicated ways. The language proposal involves more inheritance still.
Searches
It is clear that searches both within and across namespaces will be desirable. It is less clear what the default behavior should be, but it is probably most consistent with the rest of our context handling that the default context be limited to the current namespace and namespaces nested within it.