It would be nice if such a code split were to be as simple as splitting of the 'standard' mods as the app, and the rust (core mods and code), but it is unlikely to be that simple.  If we are lucky, we can start with a simple split and refine a bit from there.

 

I think the sort of guiding principle we want to include in the core and platform just those components that we want identified with the Decko platform, that we want to be shared between all platform applications.  We want to be somewhat inclusive, to make the most of shared capacities.

 

On the other hand, if this isn't the new branding, I made all references to it links so we can just rename the card.

---

The new brand will actually be "Decko". The plan is to get rid of the name "Wagn" altogether. An instance is a "deck".

---

I am starting to think we should make a distinction between the app and the platform. It might be nice to keep a small vestige of the original name as a nod to the history.

---

Well, I'd say we should keep the branding and the architecture discussion separate.

 

The branding one is pretty clear for me; "Wagn" should disappear. The value of Decko is that it harmonizes our metaphors and makes our branding much stickier. If we use different brands for different levels of the software, I would want something that uses similar phonemes and extends the metaphor. Imo, "Wagn" doesn't support any significant community/marketing goals, and it has all the well-articulated problems that prompted the rebranding in the first place. It has sentimental value to me, too, but not enough to justify confusing legions of future users. I do want to stay connected to our history. Let's find ways to do that inclusively!

 

As for the separation of powers, let's start putting proposals together. A few bits of context for where I think we are.

 

1. I expect Decko to be marketed as a platform, not an app. Each Decko instance (or "deck") is an app. The fact that you can create an instance with a lot of default context is a great differentiator, but it doesn't make Decko not-a-platform. I do want to find useful ways to separate out default mods much in the way that Rails separates out its components (see below), but I want to promote the notion that installing a deck is a great way to build your own app using the Decko platform. If Wagn is an app, what the heck is Wikirate?

 

2. I expect to rename the wagn gem to "decko" (we have the name) and to rename smartname to "cardname" (or card-name or card_name or something). We also have the name "card", which I thought we might use for a card-as-data-engine-only gem.

 

One possible way we could break this down into gems:

 

card: data model, including set modules with core events.

card-format: introduce format objects (depends on cards)

decko-system: controller, mailer handling... all the things that tie the above together

card-mod1: these we break out as see fit. each will include representations of cards needed

card-mod2

decko: lightweight gem that depends on all the above

 

That's all very rough. To me there's not much incentive to put much energy into this until we have some use cases in mind.

 

btw, I'll probably create a new Idea card for this and use the "Decko" card as a Blueprint for the rebranding. Not to say the final word has been spoken on the use of "Wagn", but I wouldn't want the Decko name (which is predominantly about making the platform more accessible) to point at an inaccessible architectural conversation ;)

 

 

 

 

---

Most of this seems right-on to my thinking. The one thing I want to speak to is "SmartName". When I created that gem, what I had in mind was federation, and I thought it important that there be a sharable component that could be an important joining point to a broader world of federated wikis. I had hoped that Ward and his group would see the importance of structured names and make that part of their foundation as well.

 

I would like to extend that hope and keep the name gem independent of the Card/Deck metaphors.

---

that reminds me. you still owe me a beer on our bet that nobody else would use that gem ;)

---

I guess I deserve that.

 

Thinking about it more, maybe calling it card_name works for my purposes as well. As you note above, card is a name we can connect to the core data models, and names are one of those core models. No reason that another project couldn't adopt the card naming system without all the elements of the card models.

---

right. it's essentially a marketing question; we're definitely agreed that we want the functionality independent. My take is that the gems will do a better job of supporting each others' adoption if they're names are linked.

 

My memory is that that bet really did happen, but I'm more excited about the idea of having a beer together than celebrating an I-told-you-so (which was only about timing, not about the whole idea). I still think we can get smartname/cardname to a place where others will use it. My take is the best way to get there is to make Decko a success. We'll get there, too ;)

---

Oh I've already tagged SmartName in my own issue tracker as something to use the next time I revisit user input, such as when they need to name the album/directory they're uploading images to.

---

Awesome! So how does this work; does Matthew get my beer?

---

No, it means that you have to buy the beer. And, you know I'm on the same page about the bet, it's been too long. I'm just calling you out for a cheap shot ;)

 

For Matthew, there are some unique things about how names work in Wagn vs. other Wikis and CMS systems. One is that there is a defined mapping to keys, which is how you know if two names that are a little different on the surface are actually referring to the same thing, and the other is that names are defined to have structure (parts). They are not flat, but are a hierarchy like a file-system (or rather like modern file-systems). Most wikis have flat name spaces, and I think that is a bad thing. Media-Wiki has the ugliness of multiple flat namespaces. We are planning on adding something called namespaces, but it would be more like the way *nix systems "mount" one filesystem into another. The Media-Wiki thing is more like DOS drive letters that MS has never moved away from.

 

We also expect names to evolve some. They are a bit English centric as is, but better than just about anything else out there.

---

Speaking of English-centric, I'm going to try to post my multilingual proposal this week. I've been working on it for a long time and it feels like it's finally coming together.

---

That will be really cool. I can hardly wait for the possibility of multi-language Decks. No doubt, the handling of names will be a very big part of it. I'm all for the model, or rather one of the optional standard models is that a cardname could have a simple cardname (what we have now, only we have variation on language) for each language supported by the system.

 

I'm sure you will have a lot more as well, and I look forward to reviewing it and seeing it come to be. It will really make Decko a standout in the market. Having the wikirate project I'm sure is a great resource and source of solid requirements for how this has to work as well as the demand for the feature.

---

Likely to happen this year?

---

perhaps 75%?

 

main challenge is getting the breathing room to know we'd be able to support increased attention for the "launch"

---

Keep me in the loop, if I'm in a good place to help support I am happy to do so.