Re: Component-based architecture in Perl

I think that people tend to more often use the word "component" in cases like J2EE and ActiveX, where there's a dominant API and a standard GUI.

Because of the many types of "plugin" APIs in the Perl world, we use lots of different names for them -- Apache modules, POE components, Mason components, DBD drivers, archivers, cache engines, etc.

It's not clear to me what "the Perl component API" would look like -- wouldn't you need different kinds of component API for different purposes?

Comment on Re: Component-based architecture in Perl

Replies are listed 'Best First'.
Re^2: Component-based architecture in Perl by Ultra (Hermit) on Jul 06, 2005 at 07:13 UTC
simonm ++ The many "component API"s float around because of TIMTOWTDI. This means that every API differs form the other to allow the frameworks to be slim, targeted, and not so general. An unique API IMHO would not be so used because everyone would have to have the same mindset, or if it would allow for TIMTOWTDI it would be a big hard to mantain monster. Dodge This!	[reply]