On Jan 9, 2008 11:39 AM, Barbie <[EMAIL PROTECTED]> wrote: > I know Adam has made a start with CPAN::Testers::Report, but that looks > at the report as a set of parts, rather than just generating the actual > report content. > > I was thinking CPAN::Testers::Report::Text (which could later sit > alongside of CTR::YAML or CTR::Email, etc) could produce the report, > although, having said that some of the data collection would sit better > in CTR, with the lower CTR::Text formatting the report body as per how > CPAN::Reporter currently does it. This would include moving > CPAN::Reporter::PrereqCheck outside of CPAN::Reporter too. > > Is this the right way forward or is there a more suitable way? > > Seeing as this would mean more work for Adam and David, I'd rather take > direction from you guys.
What I'd prefer--which may be what you're suggesting in different words--is for it to work roughly as follows: 1 - Tester tests a distribution 2 - Tester gets a result 3 - Tester instantiates an object of type CPAN::Testers::Report 4 - Tester calls methods against this object to specify the results of the test report 4a - Tester specifies the distribution tested 4b - Tester specifies the grade 4c - Tester optionally specifies additional comments 5 - CPAN::Testers::Report automatically calculates additional discrete data as applicable 5a - CPAN::Testers::Report calculates distribution name (Foo-Bar) based on distribution (Foo-Bar-0.01) 5b - CPAN::Testers::Report calculates distribution version (0.01) based on distribution (Foo-Bar-0.01) 5c - CPAN::Testers::Report determines the RFC 2822 date 5d - CPAN::Testers::Report determines the interpreter's name (perl) 5e - CPAN::Testers::Report calculates the interpreter's float version (5.008008) 5f - CPAN::Testers::Report calculates the interpreter's numeric version (5.8.8) 5g - CPAN::Testers::Report determines the interpreter's extra version (i.e., patch-level) 5h - CPAN::Testers::Report determines all configuration elements for this interpreter 5h1 - CPAN::Testers::Report determines the archname 5h2 - CPAN::Testers::Report determines the osname 5h3 - CPAN::Testers::Report determines the osvers 5h4 - CPAN::Testers::Report determines all remaining configuration elements... 6 - Tester selects a serialization-distribution mechanism 6a - Tester chooses Email 6a1 - Tester serializes CPAN::Testers::Report object with C::T::R::Email::Subject to get textual email subject of test report 6a2 - Tester serializes CPAN::Testers::Report object with C::T::R::Email::Body to get textual email body of test report 6a3 - Tester submits the serializations to CPAN::Testers::Transport::SMTP for transport 6b - Tester chooses HTTP 6b1 - Tester serializes CPAN::Testers::Report object with C::T::R::JSON to get a JSON representation of the test report 6b2 - Tester submits the serialization to CPAN::Testers::Transport::HTTP for transport In other words, CPAN::Testers::Report enables a transport-agnostic, representation-agnostic lower-level data-structure of every discrete bit of data that comprises a test report. Objects of this type can then be serialized in any manner preferable (JSON, YAML, textual) and transported in any manner supported (SMTP, HTTP). This in turn allows for interchange across serialization representations, consistency in how reports of any type are generated and parsed, are reduces or eliminates multiple competing implementations of the same concerns. -- Adam J. Foxson