[cells-devel] tk-client-task-priority

[Kenneth Tilton]

Andy Chambers wrote:
> Hey Kenny/Frank,
> 
> How did you work out the correct order of the tk-client-task-priority? 

That all arose from pragmatics, ie, solving things that kicked back 
during development.

> I
> get that tk objects have to be created before they can be configured
> and that's why :configure appears near the end of the list but why are
> the :delete, :forget tasks so high up?  What if something is scheduled
> to be deleted and configured in the same cells "timeframe"?

It sounds impossible for one datapulse to cause a declarative engine to 
decide something should both exist and not exist. That said...

The pragmatic history is forgotten, but normally one wants to clear the 
stage of things who will not be around for the next datapulse before 
introducing new information, lest the guys on death row get all busy 
with some of the new information (and new information cannot possibly 
want information that should not be there).

In your case, something is both coming to life and being purged in one 
go. Maybe a change makes the thing occur but makes a parent or 
grandparent thing decide to go away. In that case it probably works best 
to let the thing come into existence and /then/ clean it up.

But let's understand your use case a little better -- how did the 
birth/death conflation come to pass?

kt