Lance, The scheme we devise for versioning would afftect deployment and packaging. How we execute versioning in the engine/visualizer would obviously be excluded from your proposal, but the result does affect it. It might just take a while to reach consensus on how to do versioning in an appreciable manner - so perhaps there is room for an addendum later? Not sure if that's Apacheland compliant, but it's a thought.
Cheers, Zubin. On 5/5/06, Lance Waterman <[EMAIL PROTECTED]> wrote:
Zubin, I have tasked myself with delivering a proposal around a deployment API and package model. Do you think versioning belongs in such a proposal or someplace else? Lance On 5/4/06, Zubin Wadia <[EMAIL PROTECTED]> wrote: > > Paul, > > You are on the button about the "forcible termination" approach giving > users > fits in long running processes. In my humble opinion, versioning is a key > area where innovation can lead to Ode being truly distinctive. It's a > tough > problem. > > If there is a SWAT team electing to get into it, I'm in. > > Cheers, > > Zubin. > > On 5/4/06, Paul R Brown <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi, Zubin and Bill -- > > > > > Yup, it can get mucho ugly when we have multiple processes aging. > > > Shouldn't > > > these be topics by themselvesf? > > > > > > 1. Process Deployment > > > 2. Process Versioning and Deprecation > > > > Agree, or +1, I suppose, in Apache-speak. > > > > For #2, the ante is "new instances are generated by the most recently > > deployed description", and there's the boolean question of whether > > old instances should be allowed to live or should be forcibly > > terminated. (Note that forcible termination could be a big deal if > > you have thousands or millions of active instances.) > > > > It was my intention to put together an instance replacement feature > > for PXE, but it's also one of those intentions that I never really > > made good on... The idea would be that you could do something like > > create a process instance in a standalone container of some kind or > > extract an instance from the runtime state store, feed it some > > messages, tinker with values, maybe change some XPath statements, > > etc., and then shove it back in. As-is, PXE supports in-place > > replacement of processes as long as the ports for the new process are > > a subset of the ports for the old process, but there's no API to make > > it work. > > > > The "rip-and-replace" functionality would open up all kinds of cool > > things like "rewind" -- keep all of a processes various states > > around, and if you want to rewind back a couple of execution steps, > > just replace the current one with the older one. > > > > -- > > Paul R Brown > > [EMAIL PROTECTED] > > http://mult.ifario.us/ > > > > > > > >
