On Thu, Nov 20, 2008 at 4:00 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
> > > On Fri, Nov 14, 2008 at 5:32 PM, Simon Laws <[EMAIL PROTECTED]>wrote: > >> >> >> On Thu, Nov 13, 2008 at 11:39 AM, Simon Laws <[EMAIL PROTECTED]>wrote: >> >>> >>> >>> On Thu, Nov 13, 2008 at 11:14 AM, ant elder <[EMAIL PROTECTED]> wrote: >>> >>>> On Wed, Nov 12, 2008 at 1:04 PM, Simon Laws <[EMAIL PROTECTED]> >>>> wrote: >>>> > >>>> > >>>> > On Wed, Nov 12, 2008 at 11:25 AM, ant elder <[EMAIL PROTECTED]> >>>> wrote: >>>> >> >>>> >> >>>> >> On Tue, Nov 11, 2008 at 11:30 PM, Dan Becker <[EMAIL PROTECTED] >>>> > >>>> >> wrote: >>>> >> >>>> >> <snip> >>>> >> >>>> >> >>>> >>> >>>> >>> Personally I get frustrated when I read or make Tuscany demos or >>>> >>> presentations and the simple composites must be created with >>>> PaintShop or >>>> >>> some non-tech tool. >>>> >> >>>> >> This may not be quite what you had in mind but a while back someone >>>> >> created an SCA diagram stencil for Visio [1], lots of people wont >>>> have Visio >>>> >> so maybe we should create a similar template for OpenOffice Draw and >>>> make >>>> >> that available on the Tuscany website so anyone can use it to create >>>> good >>>> >> looking pictures. (Disclaimer, i know little about OpenOffice Draw >>>> but >>>> >> googling it it does seem to have a stencil facility) >>>> >> >>>> >> ...ant >>>> >> >>>> >> [1] >>>> >> >>>> http://soastation.blogspot.com/2007/10/sca-diagram-stencil-for-visio.html >>>> >> >>>> > >>>> > I'm interested in consumability and ease of use. I've tried to extract >>>> a few >>>> > things from my mental list that I think have an impact... >>>> > >>>> > For the user >>>> > Documentation >>>> > Complete extension documentation >>>> > Document common tasks +1 Ram's suggestion of document/sample >>>> alignment. >>>> > Also share README content with website >>>> > Distribution >>>> > Separation of core from extensions >>>> > Smaller total number of jars and remove all jar >>>> > Have an obvious first steps thread in the distro >>>> > Development >>>> > Improve policy story >>>> > Deployment >>>> > * Clear hosting/deployment options with samples >>>> > Clarify/Simplify domain story >>>> > Management >>>> > Debug >>>> > Restructure validation itests and index from messages >>>> > Improve tracing and document how to exploit >>>> > Runtime model dump >>>> > >>>> > For the developer >>>> > Development >>>> > * Review SPI, clean and document >>>> > * Modularity (there has been much discussion already) >>>> > * Remove IOC nature of runtime construction >>>> > * Builders structure >>>> > * Contribution processing structure >>>> > Build >>>> > Speed it up >>>> > * Structure. I'd like to separate core from extensions and >>>> disitributed >>>> > content from content in development >>>> > * Build/test with the distribution structure >>>> > Release >>>> > Need to simplify and make it easily repeatable >>>> > >>>> > * marks the things I think have to be at least considered (but not >>>> > necessarily completed) at trunk bring up. Everything else builds on >>>> this. >>>> > >>>> > Simon >>>> > >>>> >>>> Those all sound good. >>>> >>>> With "Remove IOC nature of runtime construction", thats not something >>>> I recall coming up before so could you say a bit more about that? >>> >>> >>> At the moment the runtime builder injects specific resolvers, factories >>> etc into the various runtime components. In nine times out of ten it just >>> gets them from the extension registry so I would like to remove the majority >>> of the runtime builder code and let each function do it itself given the >>> registry. If we need to allow access to some new extension in the future >>> then that doesn't involve rewriting layers of constructors. >>> >>> I appreciate the benefit from IOC generally but in this case I don't >>> think its adding anything. >>> >>> >>>> >>>> >>>> The items under "Build" seem good too, i think the easiest way to make >>>> the build significantly faster will be a reorg like you describe. >>>> Would things like itests, vtests, samples be moved to be within >>>> separate folders under the extension they relate to? I think that >>>> might be good, is it what you had in mind - so for example all the >>>> webservice things be moved to be under the webservice extension >>>> folder? >>> >>> >>> Actually I hadn't thought that far. But I like the though that we could >>> make extensions more modular to include Itest, vtest etc. This also ties up >>> with Ram's thoughts about tieing it all closer to documentation on the web >>> site also. >>> >>>> >>>> >>>> Under "Distribution" there is "Smaller total number of jars", thats >>>> come up a number of times from users, for example, a comment saying >>>> the calculator2 sample which uses the aggregate jars prototype is >>>> easier to understand, and the discussion on using JDK6 would also help >>>> with this. Not sure how we're going to decide what the themes to focus >>>> on are but I think this would be a good one to do, and if we end up >>>> with multiple distribution having an extra one using aggregated jars >>>> seems like it could be a harmless and useful option along with all the >>>> other distributions. >>> >>> >>> Agreed. >>> >>> Re. deciding on themes. I think we're getting to the stage where all the >>> ideas so far can be summarized and someone can make a proposal on >>> >>> 1. A high level set of themes >>> 2. If there is any natural order that these things have to flow in >>> >>> If none else gets to it I'll have a go later today. I have a few other >>> things to ge through first. >>> >>> I imagine there will be debate about the "how" of some of these items. >>> But that is different from agreeing that items need addressing. >>> >>> >>>> >>>> ...ant >>>> >>> >>> >> Conversation here has died down so I'd like to close this out. Here is a >> summary of the ideas that have been put forward. Apologies if I missed any. >> I took the liberty of organizing in the rather arbitrary categories from my >> post. I've had a go a marking those items that need to get done to get >> through the stage 1 that has been proposed where we bring up the minimum >> number of modules to define the base code and best practice for bringing up >> the large number of other modules. Just my view so your view may differ. >> Comments please. >> >> I would be very surprised if we don't think of more things for Stage2 as >> we go through Stage1. That's fine. People will be drawn to the things they >> really want to see fixed. I guess after we've discussed a bit we can put >> this list up on a wiki page for future reference. I imagine that each >> individual item will get a thread of its own at the appropriate time. >> >> >> Stage 1 - minimal bring up >> Stage 2 - bring up to 1.x level of function >> >> I've marked 1 and everthing else is 2. >> >> For the user >> consumability >> honing the user experience - probably overlaps with lots of these >> things >> Documentation >> Complete extension documentation >> Document common tasks +1 Ram's suggestion of document/sample >> alignment. Also share README content with website >> documentation improved to include patterns and better links to info >> in samples >> Set of docs specifically for 2.0 >> Documentatin for official SPIs/APIs >> Make complete docs a condition of 2.0 release >> Distribution >> Separation of core from extensions >> Smaller total number of jars and remove all jar >> Have an obvious first steps thread in the distro >> Re-organized samples and itests >> top notch demos and presentations >> Development >> OASIS spec support >> OSOA spec suport >> promoting graphical tools and syntax assist tools to work with >> Tuscany >> tooling integration? >> Deployment >> Clear hosting/deployment options with samples >> 1 Start with just node and and get rid on host-embedded for now - >> rethink embedding, launching etc. >> Clarify/Simplify/Consistent SCA domain story (deployment and >> management) >> Make our SCA domain to be a bit more dynamic >> QoS: Improved Policy Framework with transaction and security >> Management >> JEE/SCA integration. >> Improved JEE/Webapp support >> Work well with domain >> Complete wiring support >> Have good test framework testing all extensions in this >> environment >> Support some standard web frameworks >> Debug >> Restructure validation itests and index from messages >> Improve tracing and document how to exploit >> Runtime model dump >> >> For the developer >> Development >> 1 Review SPI, clean and document >> 1 Modularity (there has been much discussion already) / OSGI >> enablement >> 1 Remove IOC nature of runtime construction >> 1 Builders structure >> 1 Contribution processing structure >> Build >> Find a way to make the build easier. >> Single Jar with JDK 6 >> Speed it up >> 1 Structure. I'd like to separate core from extensions and disitributed >> content from content in development (contrib) >> 1 Build/test with the distribution structure >> Release >> Need to simplify and make it easily repeatable >> >> Regards >> >> Simon >> > > So it's time we got back on here. We've made a start on Stage1 in that the > minimum set of modules is up an running just about. What are the things we > need/want to do before we start on the wider themes. In summary this was the > list we captured from this thread. > > 1 Start with just node and and get rid on host-embedded for now - > rethink embedding, launching etc. > Looks like host-embedded has gone in the node rework in the equinox > branch so we need to review that > 1 Review SPI, clean and document > 1 Modularity (there has been much discussion already) / OSGI enablement > 1 Remove IOC nature of runtime construction > 1 Builders structure > 1 Contribution processing structure > 1 Structure. I'd like to separate core from extensions and disitributed > content from content in development (contrib) > 1 Build/test with the distribution structure > > A) Are the things that should be added/removed > B) who is going to do what. > > I would probably add to this list some of the "distribution" items to this > stage 1 list. There has been a reorg in the equinox branch and we should > review that. > > I'm going to ease myself in gently by looking at the builder extension > point and doing some tidying there. Not a particularly high priority but a > chance to get a feel for the changes in the code. > > Simon > I agree there should be some "distribution" items on the stage 1 list. I'd also like to bring up sooner rather than later the various runtime options - so j2se and webapps along with equinox. ...ant
