* A. Pagaltzis <[EMAIL PROTECTED]> [2006-08-16 20:40]: > Integration of heterogenous systems is much easier that way – > even subsystems for which no explicit format emitter is > available can participate without much trouble. You can easily > scale the complexity of the participants at either end of the > wire to match your needs.
Case in point: a rudimentary TAP library for Oracle PL/SQL. http://use.perl.org/~jdavidb/journal/30641 * Adrian Howard <[EMAIL PROTECTED]> [2006-08-17 09:55]: > You're right it can be a bonus. But to sell that to a group of > people who already have something that works very well, is > already integrated with their IDE, continuous integration > package, build system, etc. you've got a tough job ;-) I think it’s likely to be a hard sell precisely because it’s bad in the ways that IDE-integrated stuff is good, but very good in the ways that IDE-integrated stuff is bad. Look at the example above – how much effort would it take you to hook testing for your SQL scripts into your IDE, compared to the effort it took J. David B. to write a pretty featureful TAP emitter? He didn’t even have to write most of that code, 1/3 of it would have been enough for a primitive library, which is sufficient to hook into Test::Harness – or whatever other TAP infrastructure we’ll cook up in the future. This is exactly the kind of thing I was espousing in my other mail. Of course, the problem here is one of world view. A heavily IDE- centric developer isn’t likely to think in these terms in the first place. Perl, OTOH, has a cultural bias towards heterogenous environments and tool independence. It’s easy to imagine why TAP sprung up here. I guess the best marketing opportunity would be to target the developers who have to deal with at least somewhat heterogenous systems despite their use of typical IDE+xUnit languages – they’re the most likely to be feeling the sort of pain from their current tool that will make them receptive to the benefits of TAP. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>