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
