On Sun, 7 Apr 2002 04:06, Pete Carapetyan wrote: > 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.
That can be the case. I have a bunch of components that are not based on any published interface or anything. It was just a useful abstraction layer for me at the time. So I don't think this is a huuuge problem. > 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." ? To be honest I usually would do (d) and then suggest that it be reworked in fashion X so that it can be more generic or whatever ;) > 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. thats probably the case ;) Paul recently added some more documentation. Can you look at it and see what needs doing. Also your documentation looked good - perhaps we could elaborate on that and integrate it into the main site? > 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. > > 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. That sounds good. But then again I don't see a huge need for evolution to occur in that way. I tend to come from a more XP development methodology where you evolve both the interface and the implementation until a point where they can be considered mature enough. Anyways I would not mind seeing some of this mail and your page merged into avalons main docs ;) -- Cheers, Pete *------------------------------------------------------* | Hlade's Law: If you have a difficult task, give it | | to a lazy person -- they will find an easier | | way to do it. | *------------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
