Packs+architecture

Our architecture needs to focus on three primary Wagn "participant types". Open to see a list of what they need from the architecture.

simplicity in finding and evaluating/screening modules
simple installation, generally without interacting directly with the filesystem.
simple removal of modules
automated handling of dependencies
good starting points -- bare bones not too bare
manageable amounts of modules to install
access to good help if/when any of the above comes up short

Create simplified deployment packages for "non-admin" installs
Create complex deployment architectures for specialized application
Manage change in each class of deployment
Manage change from networks of developers (internal and external)
Create releases, Bagns
Create distributed architectures to support development, testing and collaboration across multiple wagn spaces.
Add support for other information sources important to my organization
Manage Wagn resources (storage, memory/cpu, network)

small chunks, easy to get your head around
simple, clear api
possibility to add value without tons of work
access to feedback
minimal barriers to entry

Clearly there is potential for conflicting needs. Developers want lots of "small parts", Wagneers want a few, intuitive big ones. The architecture below is aimed at addressing both:

Core

The core is basically what you have when you have no packs. Gems are modular in that rails apps can choose to use them or not. Packs are modular in that wagns can choose to use them or not. Note that with no packs there are no views, so although you could do basic data operations with the Wagn core, you couldn't load a web page. Presumably the first failure with a standard GET request would be that the renderer would look for a "show" view and fail to find it.

Names / Cards

Every module must have a card, and a unique name on that wagn. (Though it need not be universally unique). If the existing name is in use, it should be renameable on install. Note: this is not yet the case; needs design. It may be that this is not in place until the namespaces are.

Trees / Dependence

We must have a way to track what other modules any given module depends upon. Installing the module should automatically prompt installation of its dependents. With this representation, any modules representation can be tested by installing on a core wagn. If it doesn't work, something's missing.

These trees are key to meeting the needs of Wagneers and Developers simultaneously. If our modules interface helps Wagneers to find modules on the basis of high-level functionality, and the installation handles all the lower level stuff, then we've met the "big parts" need via well-assembled "small parts".

Conflicts

Conflicts should be kept to a minimum by banning direct reference to card names in any module, but ultimately they are unavoidable. Like dependencies, however, they should be trackable and identified at point of installation.

Bundles

I actually think a key part of the solution may be embracing something like bundles/distros from the start.

People installing Wagns will have very different needs / expectations. Some might mostly want it for traditional wiki functions, others for blogging, and others for more specialized wagn functions that may have been created for, say, energy audits or investment research or bug tracking or whatever else. It would be nice to offer bundles to help these folks.

Separating dependency from defaults

Defaults need to be robust and low-hassle (for wagneers). These are the kinds of considerations James has been highlighting. New installations (bags) will clearly need to have lots of "important", maybe even "vital" modules -- the kinds of things nobody would enjoy interacting with Wagn without, but they won't be "core" in the sense that they're not the root of the dependency tree.

Module dependency needs to be clean and explicit (for developers). This is an architectural / design decision we'll need to make: can the core depend on modules?

Wagn actually already has some infrastructure for reference tracking, and I'm thinking we should piggy back on and refine that (core) structure for tracking dependence references, which will be much cleaner and more complete if it goes all the way down to the bare no-modules core. (A module with no references to other modules must function and pass all tests with nothing but the bare core). There's a cool way in which modules as cards and dependencies as references means our data referential integrity and our modular dependency tree become integrated systems. Dig the wagniness there!

I'm not sure I understand why modules need a card. Maybe for the "wagneered" part of it, but you have to leave cardnaming up to that app designer then, don't you? If they have a card, what is the cardtype?

I want modules to be a card for references/dependency tracking, revision history, linkability, etc. And that's how I see WADL as requiring a module -- add the module card to the list. I want it for standardizing module interface -- we'll want ways to turn them on and off. I've mostly assumed there would be a Module cardtype (which could plausibly inherit from Cardtype?)

Sorry, I'm trying to focus on what needs core and ruby module support. I agree that would be good, but I don't think that is part of the core. There needs to be some interface from the user/admin level stuff and how it loads modules and such, but we cannot even count on the services to automatically load dependencies will be available on any given system. We could still support rake tasks pretty easily, and cards could even be fetched to tell the rake tasks what the dependency parts would be. But the point is we want to split this feature into the parts that can be wagneered and the parts that are needed to support the system/code changes in typical admin contexts.

In fact, you can start wagneering some of it to find out what you might want automation and code support for.

Is there a reason these things always go in the root of the namespace? I mean, why not have System+ or maybe *system+, or *modules+ . Is there a wagn principle that argues against such practices?

what do you mean by "these things"? Nothing inherently awful about Systems+. Could also do naming conventions. Some qualifiers:

1. Let's say I have a module called "Mapman" that plugs into some mapping software. If I name it System+mapman, that will automatically create a MapMan card. So it's messier, and it ties up the root anyway. System+ is not really a new namespace.

2. Plus cards can't be tags. So things like *options, for example, need to be simple (nonplus) cards.

Why does the tag card have to exist. I don't see how it is actually related to the plus card. It really only has a contextual meaning in the context of a '+' The '+' operator is not commutative, I see why the trunk needs to exist, but not the tag. Doesn't mean you can use it, but if it is an empty card, I don't think you should create it.

OK. Some interesting stuff in here. My approach is to learn more about what the architecture reveals to the "central participant type" - the Wagnerian Operator which seems to have been sort of skipped over in this discourse. I intuit that the relationship between naming conventions and namespaces become obvious and intuitive so that the Humans can meet the code not half-way but closer to it. I hope to find a way to get my "hand" in play here.

Did we just replace 'bags' with 'packs' in vocabulary? Should probably edit above to fix that if we have.

I think I understood that, Charley. Operations concerns are not completely invisible. My professional work has been a lot more about deploying that developing, and as you know I host some Wagns. This is very much a now and future concern. Most wagns are now deployed by wagn.org, but things are in the works that may change that a lot, and operations will be a much bigger part of the development roadmap.