>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > The work we've done on the dialog support in the sandbox is showing clear > earmarks of success. We can now support 100% of the functionality that > actually works in the original implementation, plus have addressed a number > of outstanding bug and RFE issues (plus supported a few extra enhancements > like programmatic starting of a dialog that were not explicitly mentioned in > an issue). I think it is now time to incorporate the results of this effort > back into the mainline trunk code. > > Specifically, I propose to do the following: > > * Eliminate the original org.apache.shale.dialog (and child packages) code > from shale-core. > Yes, this is pretty abrupt, but developers who only use the APIs we've > exposed for application > use will not be affected -- it only impacts those who are using APIs > targeted for "framework" > users, and those folks need to be more accomodating about API evolution. > > * Create new modules under frameworks as follows: > > - shale-dialog (copied from sandbox shale-dialog2 with package names > (etc.) > changed from org.apache.shale.dialog2 to org.apache.shale.dialog. > > - shale-dialog-basic (copied from sandbox shale-dialog2-legacy with > packgae names (etc.) > changed from org.apache.shale.dialog2.legacy to > org.apache.shale.dialog.basic. > > - shale-dialog-scxml (copied from sandbox shale-dialog2-scxml with package > names (etc.) > changed from org.apache.shale.dialog2.scxml to > org.apache.shale.dialog.scxml. > > * Update website content in a manner consistent with the refactoring > proposal I just sent out. > > * If we accept the SCXML implementation, start a vote to accept Rahul as a > Shale committer. >
+1 > As with the refactoring proposal, I've got some time available starting > tomorrow night and through the weekend to devote to these changs, if there > are no objections. > > Thoughts? > +1 > Craig Gary
