AnsweredAssumed Answered

babbling on trans spaces and dynamic spaces

Question asked by rdanner on May 15, 2006
Before the conversation of transparent layers came up on the wiki I was planning on enabling time traveling through the use of "targets".  If you have no idea what a targeter is then think of it as a query that returns a set of items from a repository with runtime context relevant arguments.  In actuality a targeter can be something much more then a ?Query? it can be full out business rules.

If I understand correctly; to time travel based on the transparent layers machine you have to attach to the repository and look through the ?lens? of the layer which is an interface ? the implementation is the actual corpus under the layer.  This means you can attach with JCR, Alfresco APIs, FTP, and CIFS and see whatever the layer sees? pretty cool.

Targets are a very powerful mechanism for allowing your staff to put rules in place that take effect on there own at run time.  I think the two concepts work well together.  Prior to the layers concept I was going to have to put a condition in the targeter for the current slice of time the rule should apply to and then allow the business team to move the notion of what day time it is that they are running under.  This might still be useful for some things, but not for wholesale time-travel.   On the other hand, just as I was going to have to introduce undesirable concerns in to the targeter for time travel, I think the same problem could be replicated by using transparent layers to execute all kinds of runtime business rules for the website.

Rules at the layers level are executed by the repository and are wholesale, and transparent to the applications using the repository.

Rules executed by the applications using the repository obviously have granularity and isolation.

What I don?t know at the moment is the implementation details of the Layers.  It sounds like the version of the folder the layer is looking at is one of the parameters of the layer.  At first I didn?t like that very much but the more I toy with they idea in my mind the more it seems appropriate.  Version is a core facet of the repository and layers are intertwined with the structure of the repository.  You will want to version the parameters and existence of a layer just like any other folder. 

So if I have got it, a layer is a folder, version pair that looks itself just like a folder but behaves with all its magical layer behavior. 

That means if I point to some other type of type of folder, say a dynamic folder (a folder which is a virtual thing, its contents the result of a query/transform) then the layer can invoke that folder and whatever version of the query/transform pair exists at that time. 

It gets a little interesting when you start moving pointers around.  You find that in previous points in times a layer may have pointed to some version but was later updated to point to some other version or destination altogether.  Something that can get pretty damn confusing and even more semantically troubling when you throw dynamically rendering folders and recursion in to the mix. 

I don?t have it all straight in my head yet but at the moment I am in a little bit of the? will I get in a [What is real?] mode if I use these kinds of capabilities in sophisticated ways. 

It?s important to figure out the syntax, the semantics, and what the user or at least the coordinator will need to be able to visualize what the hell is actually going on and some way to help people understand how the complexity they are building is evolving.

Outcomes