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 type: prototype and make a class - prototypes with sets (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.
Isn't maybe Packs the proper card to unify these ideas under? Not sure yet.
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.
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....