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

Reply via email to