WADL+solution

Where Do WADL declarations go?

In the everything is a card model, there will be a set a WADL cards for each Card Application, but where do they go in the cardspace?  Maybe System+* ?  They could be stored in the filesystem too, and maybe they will be in Wagn 2.0, to be migrated to cards later.  File system or system cards, we need to organize that namespace.  What sorts of things will be here:

I think WADL is simpler than this.  It's just a list of cards.  The code dependencies must be represented for this to work, but I wouldn't consider that part of WADL.  Wagneers shouldn't have to think about that. --ethan

How Do Changes Take Effect?

This will depend on the run environment.  Initially we don't want to have to support changing System cards on a running system, and you probably wouldn't for production systems.  Some changes may always require a restart of the server container for the app.

Modules, Hooks and Card Types

WADL declarations have roughly these three concerns.  Module declaration tell it what variants and version will be used for required module interfaces, as well as what optional ones to include.  The hook declarations declare the internal pluming and routing of the application.  None of the hook symbols need to be pre-defined, but conventionally certain hooks and usage patterns between them will be very common and quickly become standard usage.

The variants and versions issue is right on.  When you define a list of cards, it may initially point to one specific identifier of, say, a card module, when in reality a range of them might do.  So this means we have to have some way of saying, essentially "this or that or that".

I don't think I understand the hooks stuff yet, though.  I would think that modules would be interacting with hooks, but that WADL would only be interacting with modules.  Why are we elevating hook interactions?  Is this a different conception of WADL?

Finally, the card type modules supply the underlying services and render action handlers.  Through card type modules we should be able to embed any other kind of data into a card as long as the module can handle the actions the hook based patterns in use are going to send it.

Not sure I understand how these modules are any different from the first ones.

Cardtype Pattern

Rather than just access +type or +cardtype for this field, if it were a WADL defined tag, it could use patterns to find the cardtype in a variety of places.

Please elaborate (or point me to where you've already elaborated).  not sure I'm on board with +type yet.

Summary

We need a DSL to put in cards in the System+* (or similar) space, and to define that space in terms of patterns and cardtypes and whatever else is needed.  The Modules part of the DSL can drive tools to fetch the dependencies (load gems, etc.), the Hooks establishes the Card MVC patterns in a customizable way, and Card type modules provide the abstractions for the VC parts that are driven from the Hooks.