On Tue, Aug 9, 2011 at 1:20 AM, Jean-Sebastien Delfino <jsdelf...@apache.org> wrote: > On Sat, Aug 6, 2011 at 12:27 AM, ant elder <antel...@apache.org> wrote: >> 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)." > > ... > > So we're just getting different impressions. That happens :) > > IMO 'help document tutorials and samples' is in line with 'give you a > view of the composites as they are authored...' and 'integrate with > the SCA domain manager' is also well in line with 'give you a view of > the composites as they are ... configured'. > > I think it's better to have the visualization that documents a > composite closer to the composite document as it was > authored/configured composite than the result of its compilation (and > again you could apply the same principle to Java or any other > programming or composition language). I also think it's simpler to do > it this way, as I've tried to explain in the last few emails. > > You don't think the same way, and that's OK with me, plus I'm not sure > I'll be able to convince you otherwise anyway. > > I'd be interested in Nirmal's opinion too. He has already spent quite > a bit of time on the subject and made really good progress, so like I > already said, I think he should pick the approach that he thinks works > best for his project. >
The thing is with open source and Apache projects in particular in order to get code that lasts you need to collaborate, find consensus and foster others helping with your code. Of course this project could just focus solely on the approach you've suggested, maybe it would take off and be successful though we don't really have many environments yet where it will get used much like that and as you comment in an earlier email its an approach that is "...probably not going to be very popular with other people in the Tuscany project or the SCA spec group" so the chances of it being maintained after GSoC aren't great. Adding support for both approaches looks to me like it wouldn't be hard - there just needs to be one more class added for an EntityBuilder impl that can work off the Tuscany Composite objects instead of raw XML. With that done we could then use this with things like the Tuscany Shell and all the samples and demos which would make this project immediately useful and much more likely to maintained and enhanced after GSoC. ...ant
