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]> > > > -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
