"Hands" are just a group of cards made easy to copy from Wagn to another.  A hand may be configurative (ie, contains rules) or not.

 

Note that to be fully effective this will require DeckoSystems to be fully effective, but in theory it could be useful when we support simple import and export.

 

Wagneers (who aren't necessarily developers) need simple, straightforward tools to share their creations.  In other words, we want to support open-source development patterns for non-developers.

 

In that vein, there will be a need for github-like functions (if not github itself).

 

It may often be possible to generate hands dynamically, following structural references, but wagneers will often want to draw custom boundaries around what constitutes a wapplet.

 

declarations

Hands are basically just:

  • a collection (pointer or search)
  • metadata indicating supported Wagn versions, required packs, etc

We will likely want helpful search patterns to help create these pointers.

 

packs within hands?

T'would be very cool if hands could include pack code.  Best guess is that the initial hands will not include packs, but we'll shoot for this. 

 

data

Probably JSON.  See </span><span><span>improve JSON rendering.  Might be possible in other forms?  XML?

 

other key needs

  • Web API for handling JSON (or other hand formats)
  • version management design

 

 
 

Gerry said:  We also need to be able to declare module relationships and how patterns are connected to modules, hooks, and the underlying card models and their view controls.


This may just be a semantic distinction, but I see the relationship tracking as part of WADL. That seems to be to be a concern of module developers (who are most often developers), not of WADL creators (who are Wagneers). This role distinction is key to our vision for wagn in a new economy, and it has to be reflected all the way down in these architectural decisions.

  --Ethan McCutchen.....Thu Oct 15 13:33:42 -0700 2009


I just closed add ability to pass hands of cards between Wagns (not ready for action) to move the design discussion here.

  --Ethan McCutchen.....2013-02-25 17:03:40 +0000


I like this idea. I propose we do some single and batch actions:

Set class = "parameters" for a types: prototype and make a class - prototypes with Set (another class but plural)

 

I'm offering ozonefarm and openkollab as a prototypical collaborating pair at the User, group and other levels (distinct from level). These will become offerings in the Public Domain, Creative Commons and other levels.

  --cquin.....2013-02-27 20:20:09 +0000


 

We really need a fairly simple mechanism for copying (and possibly doing a little processing on) a set of cards from one Wagn to another. I guess I should make a card for that. Maybe Load a Deck from a Remote Wagn? I hate to have to create a new Wagn for each module.

 

Well, taking it up a level, we have talked about separating card migrations (just new and updated cards) from structural migration (more typical Rails migration stuff, changes to tables, etc.), and the requirements of cards for modules is a closely related function. In the long run, we want to be able to make this process pretty smooth for the users and we will have a lot of power soon in the new events systems. That should make it possible to write some good tools that can check dependencies, pull supporting cards/modules, pretty much whatever we need.

--Gerry Gleason.....2013-05-08 19:15:37 +0000

Isn't maybe Packs the proper card to unify these ideas under? Not sure yet.

--Gerry Gleason.....2013-05-08 19:16:43 +0000

maybe so. or DeckoSystems even. I just realized I didn't really read the last paragraph of your 19:15:37 comment well. Did you see that I already separated those migrations in 1.11? Look at rake wagn:migrate, db/migrate_cards, etc. They are now separate migrations! rake wagn:migrate always runs db:migrate first, then the card migrations.

--Ethan McCutchen.....2013-05-08 20:31:58 +0000

We could have a single Wagn for all of the cards in all Modules/Packs. One upside would be that name collisions would be worked out there. That wouldn't solve name collisions if someone installs a Pack with cards that share names with cards they've added to their Wagn, but it would guarantee no name collisions among official Wagn Packs.)

 

Do Packs all come with a card of type "Pack" which includes info about the Pack, configuration options, a Pointer of all cards in the Pack. links to documentation, etc.? Something like the latter seems like a necessary part for the ticket Gerry wants to start, which I'd call add a way to load a Pack from another Wagn.

 

Ethan response: They don't come with a card yet, but the plan is for them to. See Packs+architecture. Being able to load a Pack (with code) from another Wagn is actually at the intersection of Hands of Cards and Packs. I think we want to build towards that, but it's tricky....

--John Abbe.....2013-05-08 22:29:34 +0000
 
Also see:

Development Tickets (by status)

 

Ideas

 

Documentation Tickets

 

Support Tickets