Pete, >Yes Paul, I was trying to write my visuals to compliment your textual/academic >material, but no idea if that goal was acheived. > >My concern is that COP is not as understandable to some of us with lesser grey >matter, using myself as a guide. If it can't be reduced to pictures, some of us just >can't get there. Being dim witted is not always fun. I've been studying Avalon for >weeks now, and I only just "got" Roles yesterday, and only because Berin had to write >me an email! > You are making a big mistake dude...... do not confuse me with the smarter dudes present here ;-)
>A more specific fear, is those like myself, who think they understand it, but spend a >couple weeks designing some new component to contribute that assumes a new "ROLE" or >"Work Interface" which is not based on some a set of standard API's call signatures, >but instead based on their own component. > >So then the Paul, Leo, Peter, Berin and Federico have to either >a.) break the guy's heart, or >b.) tell him he has to re-write it so it works with JXXX and JYYY call signatures, >and decouple his own, or >c.) do it for him, or >d.) just bring it in anyway. >Not good choices. So how to let people know in advance and make sure that they really >"got it." ? > >The same is true with Separation of Concerns. Most of the actual work is in the code >of the implementation, but most of the VALUE is in making the ROLE or Work Interface >sensible enough for future pluggability. Again, everything hinges on that interface. >And because the committers already understand this obvious fact so deeply, it never >gets the emphasis in the otherwise excellent and very helpful documentation on the >site. It is just kind of assumed that the reader will figure out how totally pivotal >the call signature of the ROLE is to future pluggability. > >The flip side is that the promise of COP is so insanely huge. This really is the holy >grail, if it could be made to work for the average fellow. Source forge is full of >very cool things that I would never think of trying, (for example), not because they >wouldn't help me, but because of the horrible prospect of tight coupling. But give me >a way to bring them in loosely coupled......without fear of pimping the rest of >Avalon in the process, and...... > >The way I see it, Paul, Leo, Peter, Berin and Federico would publish in bold type a >page for contributors that went like this: >Want to contribute your Implementation or Component? >1. Design the interface per some very standard JBLAH or other API's >2. Submit the interface as a formal ROLE >[stop, do not proceed beyond this point] >3. When approved, then and only then, write your component. >4. If you have non-standard public calls that your component requires, that is fine, >but they need to be made in a separate ROLE so as not to pimp the rest of us who >don't want to make them. >5. Submit your component. > No, I kinda disagree. I really like the principle of evolving things up to a publication or release point. It is two ways, aspects of interface affect impl and V.V determined on a merit basis. It gets final whene releases are done... i.e. a month ago we had a heated discussion about our established ComponentManager versus what is now known as ServiceManager. Some of uss foolishly felt mugging CompMgr to be ServiceMgr was OK. >This would allow lesser brained individuals such as myself, a "See Dick Run" level of >guidance. A simple roadmap to follow, as even I can follow simple rules. And I could >then bring in my CalendarMaker component, or some other cool functionality which >would otherwise be absurd for me to consider contributing. (not a real example). And >no-one else would be pimped in the process, which is the most important part. > Man. I would just interively publish interface and impl if I were you until your nay-sayers are silent. There is also the possibility that the comp just does not fit Avalon, but hey, there are loads politely honest (and a few blunt) people here. Regards, - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
