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.
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
James said (of the nuisances of MediaWiki's modules):
As a result of these problems bundle releases have sprung up that include a set of modules already installed
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?
--Gerry Gleason.....Fri Oct 16 03:57:58 -0700 2009
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?)
--Ethan McCutchen.....Fri Oct 16 10:10:15 -0700 2009
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.
--Gerry Gleason.....Fri Oct 16 15:08:45 -0700 2009
In fact, you can start wagneering some of it to find out what you might want automation and code support for.
--Gerry Gleason.....Fri Oct 16 15:10:28 -0700 2009
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?
--Gerry Gleason.....Fri Oct 16 15:13:31 -0700 2009
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.
--Ethan McCutchen.....Mon Oct 19 16:26:44 -0700 2009
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.
--Gerry Gleason.....Mon Oct 19 18:22:45 -0700 2009
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.
--~~~~
--cquin.....Mon Mar 07 11:36:49 -0800 2011
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.
--Gerry Gleason.....Sat Mar 12 03:59:08 -0800 2011