> From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Andrew C. Oliver > > Ad homnim attacks asside Berin, I extended the discussion > that you were > already having and took the example and explained why I > disagreed with > it. If you do not like my jovial way of expressing it that > would is not > my concern.
If you intended your comments to be jovial, you should put the visual clues in your email to suggest that. I found none to clue me in. > > Sure, POI should have as few dependencies as possible. However, if > > proper componentization of POI makes sense for POI, then I > suggest you > > don't throw the baby out with the bath water. > > > > POI is properly componentized for an API. That's fine. Your posts seemed to suggest that you would not even consider componentization even if it made sense. That IMNSHO is a rediculous stance. Be objective. Honestly, I have no clue what the POI API looks like. I offered some pertinent points that proved that most of POI wouldn't benefit from componentization, however I made some room for the fact that there may be room for some components within POI. > > The suggestions we provided don't necessarily mean you have to use > > Avalon, but it very well may cause POI to have a cleaner and more > > robust design. > > > > This is a growing concern of mine. The view that everything > should be avalonized. I joined this list for two reasons: > 1. To further my > understanding of Avalon 2. To raise the issue that the over agressive > stance of this project is self defeating. It is not necessary to > avalonize every API or issue out there. Again, that comment was to prove that you don't need Avalon to use components. Components are built on the Bridge pattern which identifies *interfaces* that an implementation must satisfy. The client uses the Interface and not the implementation. There is more, but you are not limited to Avalon to use components. There are several component architectures to choose from, but there comes a point of diminishing returns. Components do not work well for representing data/documents/information. It would be foolish to try to make it work. Deciding which portions of the API should be moved out into "services" is the point of "more robust design". Whether they are implemented in a "Role Your Own" component architecture or Avalon is irrelevant. > >>So What would happen if you tied it to Avalon? Same thing. Someone > >>deploys POI with a different version of whatever Avalon > pieces and in > >>the words of Marvin the Marshian kaboom.. an Earth > shattering Kaboom. > > > > > > This is strawman rationalization and pure FUD. Have you > used Avalon? > > Yes. > > > We avoided 90% of the issues that caused Log4J and Commons > Logging to > > fail. > > its the 10% that is 80% of the work. It's the 10% that relates to misuse, or improperly specified things. We are addressing as much as we can. > > The fact that you say this crap means you have no clue what > Component > > Oriented Design is or affords you. The truth is that as > long as the > > service interface (i.e. how you use a component) remains the same, > > then it doesn't matter which component implementation you > use. It will > > *still* work. Keep in mind that this is true of whatever component > > architecture you use--whether you want to invent your own or use one > > that > > exists (like Avalon). > > > > This is not true in real world implementation. This is IMHO pure > achedemia. Look at JAMES. Try and switch the version of > Avalon. HA! Doesn't work. Define by what you mean by switching the version of Avalon. DO you mean "Phoenix"? If so, then yes, JAMES was depending on Alpha software, which has no guarantees of compatibility across versions. Now that Phoenix has reached Beta status, you should not experience those issues anymore. Nine times out of ten, the fixes were simple. Anything else, and I would really like to know about it. > > How the h-e-double-hocky-sticks do you propose to wrap with > components > > something that is not originally a component? If you want to reuse > > existing components, you have to design for components. It's that > > simple. Beyond that, take it off this list. I don't care > about your > > objections to POI API changes, this isn't the POI list. > > Give me a break. So every API in the world must be avalonized? Who > said we don't have components? Are you sure I am saying it must be Avalonized? > Normally I like/respect you alot Berin but someone really > pee'd in your > sanka today. probably true ;P > In an application. . I'll use something OTHER than POI as an example > (apparently everyone but me is allowed to use it): > > Lets say you have a tarrif resolution system. Its not based > on avalon > but it processes tarifs and outputs a result. Well fine, > does it need > to necessarily be based on Avalon? No. You can wrap it inside a > component or service (depending on which is appropriate) and your > Component based application can use it. Yes, but it can't use things that are already Avalon components. For instance, if you wanted it to be able to pull a resource from the SourceResolver, you wouldn't be able to without some complex wrapping code. The SourceResolver does help to allow an application to add new protocol types easily that POI/Tarrif resolution system wouldn't know about or otherwise use. Something like that requires the ability to have your wrapper to replace certain pieces in your API regarding URI resolution. If you do not plan ahead for that possibility, then you will code yourself into a corner, and then you make it really difficult to use your software in another context. > The issue being that things like POI and the aforementioned > system are > primitives in a larger application. They do not need to > directly depend > on the compoents etc. You can utilize the bridge pattern and stay > effectively component and/or service based. It is not necessary for > every dang API out there to support every avalon interface. I don't > think it serves Avalon or the projects that use it. I've > been watching > this for awhile and have remained silent. Again, I did not say POI should use Avalon. Nor did I say POI *should* use components. I did offer advice that would help *if* POI/whatever app used components--regardless of whether it created its own component architecture or reused one that exists already. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
