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 >
