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
