[Registry-dev] Resource lifecycle handling

[Deepal Jayasinghe]

Hi Glen,
Please see my comments 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.
I agree with you in this , but for easy of development point of view and 
version point of view I think if we make a deep copy of the resource 
when state changes will be very useful.
>
>>
>
> Hm, well the same point applies at the top level doesn't it? :)  
Well not really , or we can enforce user not to do that.
> 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.
Sound good.
>
>>> 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.  
Will that be a practical use case , I mean one resource in a number of 
lifecycle states.

-Deepal