[Registry-dev] Multiple lifecycles and renaming "Lifeycle"

[Glen Daniels]

Hi Deepal, team:

Regarding multiple lifecycles...

Deepal wrote:
>> Sure - for instance, every resource on the system might be in a 
>> lifecycle involving editorial review to watch for spelling and 
>> profanity which has "needs-review" and "ok" states.  In addition, 
>> different departments might have their own development lifecycles of 
>> the built/tested/deployed variety.
> Well as I can understand you are talking lifecycle + lifecycle 
> conditions.  So in any given lifecycle phase there may be many stages 
> (or conditions), but at any given time a resource can not be in two 
> lifecycle phases. As an example for QA state to be satisfied , there 
> might have a number of scenario checking (different JDKs , different OS 
> and etc... ) , so once all done it will move to some other state (say 
> production ). Then the resource is in production state.

No, you didn't quite get me.  I'm talking about the case where one 
designer has written the "development" lifecycle (which has 
built/tested/deployed states), and a completely different designer has 
written the "editorial-review" lifecycle (as described above).  The 
end-user / admin should be able to associate BOTH of these lifecycles 
with a given Resource.  In particular, whether a resource is 
built/tested/deployed has nothing to do with whether it has been 
spell-checked in my example - they're orthogonal.

I just want to note this again also; the notion of "phases" or "states" 
is completely implementation-specific within a particular Lifecycle! 
The Lifecycle class only processes actions and offers up a list of 
available actions.  It's totally up to the implementation how, and if, 
it wants to manage state.

The "Lifecycle" concept we have now is very powerful, and very abstract. 
   I was talking to Paul about using it in another case to add some 
custom UI which enables associating a "contact" with a given Resource 
(will start another thread here).  It took a little explaining to get 
Paul to grok quite how generic the current stuff is, and I think part of 
the problem (as it seems to be with Deepal) is the name.  So, I'd like 
to propose we rename "Lifecycle" to "Aspect", which I think is a bit 
clearer - an Aspect is simply a custom class which understands/offers 
custom behaviors that you associate with a Resource.  You can have n 
Aspects on a given Resource.  Some Aspects will be stateful 
("in-review"/"reviewed") and some may just be behavioral (an action 
which emails the Resource content to Joe).

OK with everyone?

--Glen