On Fri, Aug 5, 2011 at 6:47 PM, Jean-Sebastien Delfino <jsdelf...@apache.org> wrote: > On Wed, Jul 6, 2011 at 12:34 AM, ant elder <ant.el...@gmail.com> wrote: >> On Tue, Jul 5, 2011 at 5:15 PM, Jean-Sebastien Delfino >> <jsdelf...@apache.org> wrote: >>> A few thoughts: >>> >>> I was under the impression that the SVG diagram generator would give >>> you a view of the composites as they are authored or configured, and >>> not necessarily a view of the reduced and 'compiled' composition model >>> resulting from their assembly processing >>> >>> (I'm using the term 'compile' in the general sense here, not to >>> generate machine code but to collect and compose artifacts into a form >>> optimized form for a particular usage scenario, i.e. in Tuscany, an >>> assembly model optimized for running an SCA composite application). >>> >>> To take an example, if a composite A included another composite B or >>> used B as an implementation, and was itself included in another >>> composite C, I imagined an SVG representation for A with a link to B's >>> SVG representation, instead of an SVG representation of the reduced >>> and 'compiled' combination of A, B and C. >>> >> >> Are you sure that isn't possible to do from the Tuscany 'compiled' >> model? I think it should be, the information isn't thrown away and the >> model objects have references to all the necessary artifacts. If it >> turns out there is something getting lost then we could just fix that >> so that the info is maintained. > > With infinite time and resources everything is possible :) > > To draw an analogy with Java, it's a little bit like if you wanted to > write a Java editor. You could compile the Java source, then try to > have the editor work off the generated byte code, then go and tweak > the Java compiler to have the whole source embedded in the byte code, > then tweak it more to have it do that even with incomplete Java code > that wouldn't normally compile... Then you could even argue that it'd > be possible to do... with infinite time and resources :) > > I personally would never do that. I would just read and parse the Java > source, work off a model representing the Java source document and > syntax, keep it simple and go on with writing my editor without many > detours. > > That's the kind of simple approach that I was trying to describe... > But Nirmal should pick the approach that he prefers and he thinks > makes the most sense, I'll be happy with whatever works best for him > and the project. >
I think the comment in your earlier email hints at where this tension is coming from - "I was under the impression that the SVG diagram generator would give you a view of the composites as they are authored or configured, and not necessarily a view of the reduced and 'compiled' composition model resulting from their assembly processing" I don't know where that impression came from but its not the impression i get reading the project proposal - https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Develop+a+simple+tool+that+can+be+used+to+generate+composite+diagrams It should "Develop a _simple_ tool ...", my emphasis on simple, ... that can "1) Help to document Tuscany's tutorials and samples. 2) Integrate with the SCA domain manager to visualize the SCA domain (contributions, composites, nodes etc)." Which makes it sound to me like it _would_ work on the compiled model. Tto continue with the Java analogy, its not so much a Java editor its more like a tool to generate a class diagram for a Java application. Most of the tools diagram generating code would be the same either way so how about having it support both approaches? We're starting to finish the doc on the samples now so it would be great if this tool could help create diagrams for them. What i'd like is something like a "diagram" command plugin for the Tuscany Shell so that you can show the diagrams at the Shell command prompt. That should be pretty easy to do and a lot of the diagram generating code looks like its already capable of that type of thing so it wouldn't be too much work. ...ant
