DeckoSystems+archived discussion
Question about the +names information. Are we for sure going to change the relative name semantics when we add namespaces? There might be another solution building on the current pattern, and we could make it optional in the name gem. My point is that we should finally decide whether we are going to make the semantic name changes and whether we need to introduce them with namespaces.
Man, I'm really having a hard time understanding these comments? What do you mean by semantics? Switching the relative and absolute syntax (under the "context" banner there? Going from plus to slash? The solution proposed in DeckoSystems+names is more syntactical than semantic.
There's not a real development timeline around this yet. It would certainly be helpful to propose an order of implementation, and of course that would need to be connected to strategic rationale.
My impression is that some of the name handling changes proposed there are of greater strategic significance than namespaces. Namespaces haven't really been connected to any strategic imperative, but the relative name handling ("context") really impacts usability and would be nice to have fixed before Decko 1.0.
Now I'm not totally following you either.
Ok, it is mainly syntax, but I'm talking about the interpretations in context, the proposed /, //, /// stuff is syntactic, but we don't propose a syntax for the current + based names where +A is relative. +A is like A in the proposed syntax, and A is like /A, or really //A, and we don't have any syntax for the other two semantic possibilities. I'm just asking if you think this change is in the cards for the near(ish) term and if we actually need to do it to support any kind of multi-deck scenario.
We go through this all the time on new features and often we both have several important points. It seems that you either object to or don't fully grasp why I use the language of namespaces in order to separate concerns about the mechanics of handling names, and mapping those onto (mainly Card based) data resources.
For me, namespaces (as I'm using the term) are a necessary first step towards considering any approach to multiple decks. It seems ironic now that when I proposed this long ago, I was only thinking about hitching wagns and you suggested the multiple local deck scenario. I've come to realize that scenario is at least just as important and a good target as a first step. It is the right step to work out a lot of the internal issues around name handling, and now I think that Wagneers (or Cardiacs) will find lots of uses for this once the have it.
I'm happy to help flesh out strategic plans, but it would be good for you to provide a framework for that. I've laid out my use case in a bit of detail for you and I'm just trying to take the straightest path to supporting that. I have learned a lot from you over the years about chunking the work into manageable pieces, and that's what I'm trying to do here. The feature goal is local Decks and namespaces are a necessary step. If you don't think they are needed, then I'm not communicating what I mean by namespace very well.
Perhaps I should clarify something. I'm very much on board with the vision of DeckoSystems (formerly WagNet). And, from a geek perspective, I'm super excited about namespaces both local and remote. That's why I put in all the energy designing them. (Not trying to claim solo authorship or anything – you and I both banged on that stuff a bunch – just trying to claim some street cred for caring about it!)
When I say that they haven't been connected to a strategic imperative, I mean that we haven't concocted any sort of strategy around how we're going to introduce those things. It's all tech and no community at this point. Very few people are using Decko as of yet. If that doesn't change, Decko is not too likely to thrive long enough for us to reach the DeckoSystem vision.
The strategy we have begun to articulate (so far) is around Decko 1.0. When we have (a) discoverability, (b) a mods API we're ready to bless, and (c) documentation we can go for some earned media and start building community around mods and other support structures. There's a good bit of work to be done on all three dev fronts yet, and there's a TON of work that needs to be put into (d) building support structures for mod developers. We don't really have any proto plans there, despite a very strong strategic imperative!!
When and how does DeckoSystems come along? I don't know, nobody has articulated any real strategic framing there, afaik. (Yes, it's probably my job, but I haven't done it) That's what I meant when I said the namespaces haven't been connected to a strategic imperative. We all want DeckoSystems, and we've had some great discussions about how it would *work*, but nobody has strategized about how to make it *flourish*. That cardists "will find lots of uses for this once they have it" is only true if we have a community.
Until that's in place, I can't really give any great answers on timelines.
I wasn't calling you out on the whole namespace, etc. thing, but specifically on multiple local decks. I'm saying that it was your idea, I didn't even understand what you meant at first. Now I think it is a really good idea and maybe a good stepping stone.
What I'm saying the strategic opportunity is that we can start putting in the support for DeckoSystems before we are ready for all the complexities of a network of Decks. I'm not as hot on this idea as I was when I last commented. The use case of a card based app that connects to models in an existing rails app would be able to make great use of this idea.
I'd still like you to tell me what you think about the syntactic questions related to the different relative contexts as you outlined in the name exploration. I think we should decide sooner rather than later what our plans are for that. It's a big change, so we should either do it or not, and not wait until we have to.
Are you asking whether we want the syntactic changes (especially "+" to "/") before Decko 1.0?
The argument against doing it right away is that it's not necessary for generating community. It's kind of a "get to market" imperative. Without discoverability, mods, and docs, there's not much reason to go to market. The same really can't be said of naming patterns.
There are lots of other would-love-to-haves out there. I don't like how we handle uploads. We need previews. Systemic rollbacks. Query editors, moderation support, aliasing.... I can think of tons of things without even looking at tickets, and I haven't even mentioned any of our big bugs. But I disagree with "either do it or not". There's a ton of work involved, but the migrations won't be that conceptually challenging, and they'll probably be optional (because we'll support backward-compatibility options).
It comes down to this: we need more people involved, and that's not a major step in that direction. discoverability, documentation (which is really about developer discoverability) and api. That's what's going to get us there.
Well, before or after 1.0 is one question, but I was asking more generally. I'm arguing that, if we are going to do it, it should be more on the soon side. You're probably right about after 1.0, but if it is done at all, we should put it on the roadmap not too far after that.
I think what I'm arguing is that we probably shouldn't change that after some point. The potential headache of the migration both argues for post 1.0 timing, but not too far down the road so that current practice doesn't spread that much before replacing it.
First question is should we do it at all. I think we want it long term. Which character isn't that important, that could even be translated inter-site, but the meaning of leading joint(s) is critical to get right soon.
If "not too long after 1.0" is a good enough answer for you, then I think I feel good committing to that. I think the syntax is smarter and the semantic enhancements are ultimately needed for DeckoSystems.
I still think most of the attention right around Decko 1.0 will be focused on fleshing out the Decko 1.0 priorities (like support for mod developers), but as we begin to shift our focus towards Decko 2.0 (the centerpiece of which will be DeckoSystems), the very first part of that we'll want to focus on will be this naming stuff.
Yes, that's exactly what I was asking for. I was pretty sure we were committed to that change at some point. Decko 1.1-1.3 or about that seems about right. Then the new syntax (/, //, ///) will become important as we get ready for 2.0, but we should make the basic switch from 'A+B' and '+B' to '/A/B' and 'B' as soon as practical.
To follow on a little about what the path looks like. Up to the point we start actually adding namespaces and need the extended semantics, we are in the "one deck case" and that should always work (almost) exactly the same as a single deck in the multi-deck case, when it doesn't have // references. You might argue that /// is more primitive in that it refers to part of the web address which isn't really inside any namespace. We might want to add that before having namespaces where // in important. That's because // is an explicit inter-deck reference and /// is an external reference to the containing website.
External references are a whole different can of worms, for now just a link, but could be a reference to discoverable resources.
I say 'almost', because I think that the multi-deck case might have implicit references to the other namespaces. Missing cards might be found in another namespace, or rule lookup could include multiple namespaces. I would expect the local namespace to always have priority here, but we'll get a lot of power from namespace search paths and the like.
Trying to get a bit more clear about the terms. I think we (I) have been overusing namespace, although that is a concept we will share across a number of features. Representationally, right now, keys are unique on their own, and we will be introducing one or two new fields into cards that will be scopes (in the rails sense of scope: modifiers on associations and the like) for keys. We will add language, and probably deck_id at some point, and keys will be unique for any value of language and deck_id. This is a restriction at the DB level where the key is required to be unique in combination with the fields that select a namespace.
That is the minimum restriction. With some uses of namespaces, there are additional restrictions. When a key is used in the universal language (NULL language column in the current description), the scope is all languages. Probably can't make that a normal kind of DB constraint, but it would be enforced by the decko code.
Now, this blueprint is more about joining the namespaces of independent (I often call that a remote deck) decks, and as namespaces per se, not much is added with a remote deck. The rule scoping can now become non-local, but the logic of it isn't any different than with scoping multiple namespaces in the same decko instance. The complexities of remote decks is more about connecting, caching, authenticating and synchronization.