Pattern Cards+implementation+module outline

On 10/13/09 6:40 AM, Gerry Gleason wrote:

On 10/12/09 6:03 PM, Lewis Hoffman wrote:

On Sat, Oct 10, 2009 at 5:47 AM, Gerry Gleason gerryg@inbox.com wrote:

So we would have these chunks to implement cards:

1. Card content model (we haven't talked about this much, but I think this is where the hooks Lewis is talking about comes in. Task: catalog the content processing we do now: wiki-rendering to handle [[]] and  stuff, slot based type editors, other type rendering
2. Card naming model (the semantics of the virtual fields, name and key, + segmentation of names)
3. Card storage model (Wagn is a flat namespace derived directly from the naming model) We have just scratched the surface in these discussions about how we might want to extend Wagn with respect to namespaces, multiple wagns refering to each others content. name resolution and scopes/contexts.
4. Change model (i.e. how we handle revisions) -- I will come back to this along with Ethan's question about what I said earlier about revisions.

I like these broad categories. I'm a little fuzzy about Card storage being at the same level-- it seems like there's a lot of change/revision handling and content processing that we just wouldn't do if the card were actually stored on another wagn.

I agree, this is fuzzy. I'm going to address this in a separate post to keep this one shorter.

Gerry

Coming back to this as a separate topic ...

I identify this as a topic at this level, not because of all the possible technologies that might support many low level storage models, but because of the connections with namespaces and the languages (Wadl, WQL, WPL (Wagn Pattern Language) or whatever variants emerge) that are part of the card system. The reason storage models matter at this level is because of the possibility of migrating Wagn content, sets of cards from one or more shared namespaces (decks) and between these spaces. At the model level identifying a collection of cards, what I'm calling a Deck they way wagn.org Cardtype "Deck" does as the core abstract model for cards.

I want to keep the simple model of a "namespace" as a specific "deck of cards" as a building block for more complex systems. Then I can build virtual namespaces from sets of namespaces with specific storage model level relationships. In a language context, I can bring in all the ideas of contexts and binding that we have in the HLL context (Ruby and Rails here, but we want to support translation of this model to any language platform). One deck the most basic binding. in LISP they created an "a-list", which was just a list of atoms (symbols) and values, then as the language developed the basic a-list could appear in different context so implement static and dynamic binding ideas. In modern usage this is a hash object, here a hash of "name" to "card".

With these namespace/context tools avaialble to the language designer, I want to also give tools to the systems designers. Here we may be managing a knowledge base for a whole network of projects, maybe several of them are already on wagns and I have ten wagneers building cardsets as tools for all of this. And that is just one of many projects I'm working on as a systems analyst and designer. I'm using git to manage releases that are propagated to test, development and production instances. I'm also presenting users with a number of "unified" namespaces that are really the "union" of different wagns that depend on the users "subscriptions" whether automatic based on roles and groups or sign-ups.

And the "production" instances include both internal and external resources. Externally I have a whole ecosystem of Wagns and WagNets that I am deploying as well as dozens more that I connect to as resources. My flagship deployments for MetaCurrency and FlowPlace are pushing the state of the art in Wagn, and are composed of distributed cardsets served up by a network cloud of "simple" carddecks and a lot of complex machinery to move the cards and find them wherever they are distributed to.

Now do you see why I want to have something about storage models that penetrates to the core of the wagn languages?