[Registry-dev] Resource lifecycle handling

[Glen Daniels]

Hi Deepal!

Thanks for the feedback.  Couple of clarification responses below:

Deepal Jayasinghe wrote:
>> So in *some* cases, we'll want to have particular directories in the 
>> Registry for particular states - for instance it definitely seems 
>> appropriate for some users to have "/qa/"  and "/production/" or 
>> "/tested/" and "/deployed/".  When something has been approved after 
>> testing, actually copying to somewhere like "/deployed/" seems good, 
>> since the production system is probably running pointing it's 
>> configuration at the "http://registry/deployed/" URL.  But there are 
>> other transitions (for example "ready for review -> reviewed" which 
>> might not warrant a copy, just a state change.
 >
> Well I can not completely agree with "ready for review" and "reviewed" 
> transitions. Because once you review you might do some changes. So it 
> will not just state changes , I do agree we can find many instance where 
> when we do such transitions changes with no content changes.

I was thinking that changes could occur while the resource was in the 
"ready for review" state (you could also think of that as "in review") - 
it might go through several versions before passing review, but once 
reviewed there still might not be an explicit copy to a new path.  So 
it's not changes to content that I'm calling "copies", it's changes to 
the path.  In any case, I'm glad we agree about the possibility of state 
changes where nothing else changes.

>> This is why I'm reluctant to tie every state to a top level directory. 
>> Also, I'd like us not to enforce states as top level directories 
>> anyway, since it's very possible that some people would rather have 
>> "http://registry/myDepartment/services/deployed" than 
>> "http://registry/deployed/myDepartment/services".
> Actually I had a chat with Chathura before sending this mail , then we 
> found out there can be instance where resource can have name like 
> deployed. Let's take following as use case , say we have resource 
> hierarchy like below
> 
> http://registry/myDepartment/services/foo
> http://registry/myDepartment/services/deployed
> 
> Then when we do the transition changes into 
> "http://registry/myDepartment/services" we have to copy the resource into
> 
> http://registry/myDepartment/services/deployed
> 
> Then you can find the problem we are going to encounter. Therefore to 
> solve that problem I had to introduce top directory hierarchy similar to 
> SVN model.

Hm, well the same point applies at the top level doesn't it? :)  This is 
exactly why I hold the opinion that we shouldn't bake in any notion of 
particular directory structures except as part of particular lifecycles. 
  When a given user decides to install a given lifecycle, they are 
making a choice (if that lifecycle mandates control of particular parts 
of the path) to restrict the use of some paths in very particular ways. 
  Which particular paths are used are up to the lifecycle - and in fact 
might even be configurable....

MyLifecycle {
   void transition(RequestContext rc, String action) {
     ...
     if ("deploy".equals(action)) {
       // Get the deploy path property
       String deployPath = resource.getProperty("deployPath");

       // Default under "/deployed/" if not overridden
       if (deployPath == null) {
         deployPath = "/deployed/" + calcPath(resource);
       }

       registry.put(deployPath + name, resource);
     }
   }
}

This would allow me to use the same lifecycle in different places in my 
hierarchy, with Handlers which automatically set the "deployPath" 
property correctly for the different places.  For instance every 
resource under "/myDept/services" could use "/myDept/services/deployed/" 
as the deploy path (with the understanding that this reserves that 
path), and other departments might use the top level default.

>> So I'm envisioning something like this:
>>
>> Each resource can be on potentially multiple lifecycles.  On the Java 
>> side, we have something like:
> Its depend on the way you identifying the resource , if we going to 
> identify the resource be its path then resource can have only one state 
> at any given time.

Not in the model I suggest.  Since each lifecycle can potentially use a 
different property or properties to represent its "state", a given 
resource can be in many states at one time.  Example - the WSDL for a 
service might be both on a "testAndDeploy" lifecycle (much like we were 
discussing earlier), and on a "writeTutorial" lifecycle.  The tutorial 
lifecycle expects 1) demo code to be written, 2) a web page to be 
written, and 3) the tutorial to be deployed to the company website after 
review.  This path can be completely independent from the testing and 
deployment path for the service itself.

Make sense?

--Glen