Gerry: I'm thinking this isn't the right solution. We can have rules for Deck+*remote_mount+*type_plus_right defined in the remote deck module that are virtual attributes inside the namespace that reference the mounting context.
Ethan: no idea what you're suggesting or what you're objecting to. context, examples, and rationale would all be useful.
Gerry: Well, this document needs a lot of work, or maybe better to be split into a number of contexts. I got a little sidetracked while just trying to update the languange a little. Right now, I'm mainly concerned with locally stacked decks, which isn't what this section was really addressing.
I was proposing solutions relating to remote decks, which is a concern, but not an immediate one. I didn't like your solution about requiring that any meta-data about the remote deck would have to be in the local namespace/deck.
Starting by filling in your example a little:
/deck1 is a remote deck, therefore:
/deck1/any/path is in the remote deck, so:
/deck1/*remote_mount can't show me data that's from the representation of the Deck card (/deck1)
I'm suggesting that this code rules for the card:
/Deck/*remote_mount/*type_plus_right could be part of Deck (remote) module.
Ethan: When you re-read this, do you get a sense of how hard it is to follow? You never said what *remote_mount is or who wants to know what or why.
I think this is fairly simple. If a card has info about the remote (mounted, stacked, whatever) deck that always applies to that remote deck, it should be in the remote deck.
If it's info about the remote deck that only applies to a given installation (mounting stacking), then it's local metadata, and it should not be in that deck. It could look like /localmetadata/deck1 but not /deck1/localmetadata, because the latter is inside the mounted deck namespace
If you object to this, can you give some real examples (real examples don't involve foos or bars).
Or we may work out a different solution where *remote_mount is a virtual card in any remote deck that can access the Deck card that connects the two namespaces. I think the important questions raised here is exactly how different card features change when we have multiple decks. Can a rule match when part of the pattern match (the left-type in the example) is in a different Deck?
Ethan: nope. Because if you have /deck1/X, then /deck1 is not the left, it's just the deck/namespace. X is a simple card.
A bigger question will be about how rule cards are found. If I have a (local for now) Deck with rules in it:
/deck1/Basic+*type+*read
Does that only apply to cards at that level and below? Let's say we have two added Decks:
/deck1
/deck1/my_decks/deck2
So, the following cards would get (or not) the rule from /deck1 (assume all are Basic):
/foobar root deck rule
/deck1/foobar /deck1 rule
/deck1/my_decks/deck2/foobar /deck1 rule
Ethan: this is a very good question. I don't think we've really worked this out. My suspicion is that we may want to start by mounting only decks with complete rulesets (local rules won't effect them) and making it so that local decks typically do inherit rules.
In other words, any deck gets its rules from the root namespace of its origin.
DeckoSystems+names+gerry comments