Thanks Steve. I'm going to shut up now though to provide harmony. At least someone understood.
-Andy Stephen McConnell wrote: > > For what its worth - I think Andrew's opinions are completely > appropriate for this list. > > One of the most frequent questions I get asked "off-list" is "when > should I use Avalon" in the process of building a new system. The > Avalon component model is brilliant in the right scope - generally, that > scope is reasonably easily established along the lines the Berin > described. Another consideration is re-use which has not been raised. > There is a balance between using the Avalon patterns (and inherent > dependencies) and the consistency that this provides across an > implementation. Sometimes that consistency isn't justified. My take is > that Andrew is putting forward a case where it isn't justified - ok - it > may be a point to debate - but without any doubt - the subject is > dealing with Avalon boundaries and that is completely relevant to this > list. > > Cheers, Steve. > > > Berin Loritsch wrote: > >>> From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Andrew C. Oliver >>> >>> >>> >>>>> Now, I'm dealing with a problem I already had with POI (we want to >>>>> avalonize it too probably). >>>>> >>>>> >>>> >>> We do? I don't. Wrapper it with an avalon thing, but I'll -1 the >>> hell out of any attempt to make the bits and pieces avalonized. And >>> I'll fly over to Italy and beat you (nkb) with a wet noodle if you >>> mark anything with LogEnabled in POI. Its inappropriate IMHO in a >>> low level API. >>> >> >> >> Andrew, there is no need to grandstand on this list. If you want >> to dispute the componentization of POI then do it on that list. >> Do not spout your objections here, it is not the appropriate >> list. >> >> >> >> >>> SoC = that which wraps or needs poi to fit it into its own component >>> extraction. POI just needs to worry about reading and writing the >>> file formats it works with, not about fitting into any particular >>> component model. (We have folks who have asked to turbineize it >>> too). If Morphos is Avalonized or the HSSF Serializer that makes >>> sense. The API does NOT make sense avalonized. POI should have as >>> few dependancies as possible as what it is concerned with is VERY >>> limited (by design). (I can't take credit for that...thank Stefano >>> -- I disagreed with him at the time but I see his wisdom) >>> >> >> >> 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. >> >> 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. >> >> >> >> >>> At one time we thought it made a lot of sense to make POI use log4j >>> so that we could leave lots of tracing info in it for autopsies (if >>> POI couldn't read/write a file and died, we could trace its life). >>> But what happened when people tried to deploy POI with their existing >>> log4j application that used a different version of log4j? Death and >>> destruction and for want of deploying something that they wouldn't >>> want to log in production anyhow (1000x slower). >>> >>> (and we tried commons logging but it didn't really solve that problem) >>> >> >> >> And how does this relate to the _Avalon_ list? >> >> >> >> >>> 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? >> We avoided 90% of the issues that caused Log4J and Commons Logging to >> fail. 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). >> >> >> >> >>> So in short APIs stay APIs. Things which need them as components get >>> component wrappers. The dependancy tree stays clean. >>> >> >> >> Again, this is not related to the Avalon list at all, take it up on the >> POI list. >> >> >> >> >>>> In which case I would create a set of active/behaviour orientated >>>> classes. >>>> Something like OLEComponentVisitor. These "behaviour" >>> >>> components I would >>> >>>> strongly recomend use Avalon interfaces if you can. >>>> >>>> >>> >>> -1 While wrapping it is fine. Making POI APIs depend on Avalon is >>> just silly. >>> >> >> >> Take it up on the POI list--I don't care about your infightings as long >> as it doesn't infect our list. >> >> >> >> >>> -1 - Wrapping makes sense. Heck if I were writting an application >>> that I deemed it appropriate I'd wrap it in Components and Services. >>> But not in the core API. NOT everything tht CAN be avalonized should >>> be. Less is more. >>> >> >> >> >> 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. >> >> >> -- >> To unsubscribe, e-mail: >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> >> >> >> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
