close fullscreen

Original intro:

 

 

A ton of this vocabulary is still in flux, even at the highest level.   Are these Extensions?  Modules?  Are they all Modules but Extensions are ones that are not part of the core?  What's our terminology for distinguishing between mini-applications built solely with cards vs. those that involve code?


...and nobody is commited to that "WEAPI" term.

 

I'm happy to bring more folks into those discussions if interested, but I don't really want to have them here.  For present purposes, I'm using Modules and Extensions pretty much interchangeably, and I'm specifically talking about extending wagn's capabilities through code.

 

 

With the implementation of this blueprint comes a bunch of things that we want to have clear vocabulary, which may include changing the meaning of terms that were already in use. None of this is fully settled yet.

 

0. Group of cards (exchanged between/among Wagns

Hand

 

1. Any chunk of code (and cards) generated that use the functionality implemented from this Blueprint.

just the code

Proposed: Module

Related terms — private |whatever| for code you develop for use on a Wagn you're hosting, and public |whatever| for code you develop with the idea that others might use them, and which may be distributed via wagn.org

 

2. Any such code components that are built in to new Wagn installs by default (and without which Wagn may not even function).

Proposed: Core module

 

√3. Any such code and card content that are not built into new Wagns by default.

Code, cards and

Proposed: Add-on, app, pack,

could be module, vendor or gem

 

4. The "extra" functionality & data already connected to some groups of cards (specifically: Cardtypes, Roles, cards with accounts, Files, and Images). These will be implemented in the way described in this Blueprint eventually, but will most likely be around for at least some time after this Blueprint is implemented.

Currently: Extension

 

May be helpful to look at this list of different kinds of chunks that might get developed:

help edit space_dashboard

Kinds of modules

It's helpful in this to consider some specific modules people might develop, and what kinds of things people might want to do in modules generally. Even better to flesh them out as user stories and tag them "Packs".

  • A module enabling adding custom tabs (at the top level, not just in the Related tab) -- now this will add/modify the cascading menus on the 'gear' icon.  Includes full customization of the theme/UI or the gear.  This is both changing the look/feel and changing the contents of these controls.
  • A module exposing content from an external database or web service in Wagn cards. (Note that databases with a web API can already be accessed via HTML cards, and even if you want to massage the HTML they return, you can do that via Ruby or Script cards.).  For example, Meta-currency flows associated with some or all cards.
  • Adding cardtypes:
    • an improved Image cardtype which exposes image card metadata from their files, such as +*make and +*model of the camera that took a photo.
    • a Contacts cardtype (possibly involving several cardtypes) managing relationships among people, organizations, addresses, phone numbers, etc., possibly integration with LDAP and other systems, etc.
    • Table cardtype
    • The Cardtype and/or *right sets used to access external data as above.
  • Adding views:
    • display a Pointer or Search (of Numbers) as a bar chart
  • (add more)

Keep in mind that this initial API is not aimed at making all of these easy, and obviously many of them will involve non-blessed methods.

 

relevant user stories

 

 

 

 

 

Thoughts?

Hoping that having a clear vocabulary might make our exploration more accessible to others.

  --John Abbe.....Wed Feb 23 08:10:17 -0800 2011

Extension isn't going to be changed that much, the change is really more implementation than functional. We don't really want API users to even learn the current meaning because that will be gone by the time they see the API.

 

I'm now more confused between "Core Modules" and "??? (new)?. I think what we intend for the former is pretty close to what you have there. It is stuff like Renderers that you need one or more of. RichHtmlRenderer will be like that. Hard to call it a module, though as it isn't clear it can even be swapped out, but in principle it can. For example when we have XML, the XmlRenderer will likely be core. It isn't that Wagn doesn't work without it, and it could even be optional, but it is really deeply embedded in Wagn. The main thing may be release synchronization much as you have with Rails where there are many modules at the same version number, upgraded at the same time.

 

Card Modules for stuff like: Permissions (probably also Core as are many of these), Roles, Users (and accounts). Here we also expect many user contributed modules as well.

  --Gerry Gleason.....Wed Feb 23 09:52:15 -0800 2011

re "Core Modules" and "???" - the former is any module in the core, the latter probably is fuzzy and not useful to distinguish from modules in general. I thought maybe "Card module" for "???" because I was thinking of modules that add custom data to a Cardtype, but accounts (a current extension) obviously breaks that definition. It could be Set module, but yeah, I think it's too broad/fuzzy to be useful, so I'm removing it. Just for reference, it was:

 

??? (new) — this will be the new term for the added functionality that used to be called an "extension". Existing code will be refactored to use the module architecture. This currently includes extra functionality for account cards and Cardtype cards (which will become "core modules"), and it will now become much easier for developers to add their own (which will be "extensions" in the new sense, unless they are made part of the core Wagn installation).

  --John Abbe.....Wed Feb 23 14:06:54 -0800 2011

"Extension" seems to have lost all semantic content here. If you aren't making reference to what feature or component that is being extended, or there is some part of the feature that logically extends the base, then the word is redundant and confusing.

  --Gerry Gleason.....Wed Feb 23 14:59:25 -0800 2011

My understanding (which could of course be wrong) is that we'd like to stop using "extension" for the extra stuff now associated with cards-with-accounts, Cardtypes and Roles. To do that, we need a new term for whatever that is, which will only be in use until we implement that functionality with modules. After that we'll instead talk about the cards-with-accounts Module, Cardtype Module, and Role Module.

 

The reason for this shift is so that we can start using the word "extension" for modules that are not part of the core.

  --John Abbe.....Wed Feb 23 15:05:13 -0800 2011

More exactly, that implementation feature is going away. It isn't clear how quickly, so there is potential for confusion during the overlap period. I don't like generalizing it in that way, as I think modifiers on Module gets at that better.

 

In my view, if we keep using that word at all as blessed vocabulary, that it should have a meaning connected to some core feature that is getting extended. What we had would be "Card extensions" and we may have some remnants of that for a while. What I'm saying is that it isn't a noun on its own, it has to modify another noun.

  --Gerry Gleason.....Wed Feb 23 15:13:42 -0800 2011

To clarify an idea (not advocate for it), it's possible to thing of "extension" as extending Wagn, not a particular structure or feature.

 

So one notion was that wagneers would end up rarely using the word "module" but instead always using the word "extension".

 

Back in the advocacy space, I really think there should be just one word that most Wagneers would encounter for all of this before they venture into actual module development (as in, if you're only installing and uninstalling, not writing anything). "Plugins" already has a specific rails meaning that we may or may not want to attach to. "Add-ons" is another option.

 

The other thing I'd like us to get clear on is how/where these words overlap with non-code structures in wagn.

 

It might be helpful for us to use this card to make one list things we want to name, another list of possible terms, and then propose ideas for mapping them. Maybe?

  --Ethan McCutchen.....Wed Feb 23 17:03:35 -0800 2011

I've reworked the section up top along the lines that Ethan suggested, and am thinking maybe it's good to not even think about terms yet, but just see if we all think that those are the four things we want terms for? Anyone seeing a better way to slice the pie, more/fewer/different categories?

  --John Abbe.....Wed Feb 23 22:16:06 -0800 2011

I realize I'm a little fuzzy on 4. Does it only apply to the existing code for the five groups listed there? (I'm using "group" instead of "set" because we can't (yet at least) define the set of cards with accounts :-P.) That is, is it true that no chunk of code developed as described in this Blueprint will fall into category 4?

  --John Abbe.....Wed Feb 23 22:23:54 -0800 2011

This is looking really good now. We may be able to clear a lot of this discussions. Maybe leaving behind the few items that are not completely resolved.

 

Ethan, right-on for the "what to call it on first encounter" (canonically). Add-on or AddOn (inflected for context) works for me.

  --Gerry Gleason.....Thu Feb 24 05:04:22 -0800 2011

I started this in hopes of resolving the vocabulary very soon, thinking that having it be consistent on Packs+api will make it more accessible to others (and us for that matter). Does that seem worthwhile?

 

If so, maybe a call with us plus Lew?

  --John Abbe.....Thu Feb 24 14:42:51 -0800 2011