Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Documentation
    • Labels:
      None
    • Environment:
      All

      Description

      I am creating this to start discussion about M3 plans. I will attach a document of my proposal which has been contributed to and reviewed by several people, but is by no means locked down. Please review and comment.

      1. stonehenge.zip
        819 kB
        Pablo Mariano Cibraro
      2. Stonehenge+M3+Proposal.doc
        729 kB
        Kent Brown
      3. stonehenge-m3.docx
        112 kB
        Pablo Mariano Cibraro
      4. Stonehenge M3 Proposal.docx
        691 kB
        Kent Brown
      5. TestEngine.csproj
        11 kB
        Ben Dewey

        Activity

        Hide
        Kent Brown added a comment -

        Attached documented proposal.

        Show
        Kent Brown added a comment - Attached documented proposal.
        Hide
        Kent Brown added a comment -

        Uploaded in older .doc format for compatibility.

        Show
        Kent Brown added a comment - Uploaded in older .doc format for compatibility.
        Hide
        Scott Golightly added a comment -

        In general I like the idea of the proposal and think it will make the interoperability testing easier to use in helping me and others test and debug interoperability issues. I did have one point that I would like more clarification on in the proposal.

        My question really is about who can create tests and who can call the hosted endpoints. I am envisioning a scenario that does not seem to be addressed in the proposal. The scenario I would like to see is that a user can run the tests or see the results of previous tests between hosted endpoints that have been set up by the Stonehenge contributors (steps 8-10 of the walkthrough). They could then call any of the endpoints with their code and if the call fails examine the messages to see what is different.

        When I look at the HostedClientResult class it has 2 properties (requestMessageLog and responseMessageLog) that would appear to allow me to retrieve the entire contents of the messages sent across the wire. If this is the case I can see where it would be very valuable to have the messages captured from a successful test in the documentation for that test so I could compare that to my failed case.

        Along with that I wasn't sure what was meant by the statement "Results are stored." in step 10 of the walkthrough. If there are multiple results stored (including any that I run) then searching through a large set of results might actually deter me and other users from trying this. I would propose that there be 1 result stored long term as the "correct" results from the test. This could even be added to the documentation for that scenario. Users could then call any of the end points and retrieve the messages from the results but these would not be stored by apache.org.

        Show
        Scott Golightly added a comment - In general I like the idea of the proposal and think it will make the interoperability testing easier to use in helping me and others test and debug interoperability issues. I did have one point that I would like more clarification on in the proposal. My question really is about who can create tests and who can call the hosted endpoints. I am envisioning a scenario that does not seem to be addressed in the proposal. The scenario I would like to see is that a user can run the tests or see the results of previous tests between hosted endpoints that have been set up by the Stonehenge contributors (steps 8-10 of the walkthrough). They could then call any of the endpoints with their code and if the call fails examine the messages to see what is different. When I look at the HostedClientResult class it has 2 properties (requestMessageLog and responseMessageLog) that would appear to allow me to retrieve the entire contents of the messages sent across the wire. If this is the case I can see where it would be very valuable to have the messages captured from a successful test in the documentation for that test so I could compare that to my failed case. Along with that I wasn't sure what was meant by the statement "Results are stored." in step 10 of the walkthrough. If there are multiple results stored (including any that I run) then searching through a large set of results might actually deter me and other users from trying this. I would propose that there be 1 result stored long term as the "correct" results from the test. This could even be added to the documentation for that scenario. Users could then call any of the end points and retrieve the messages from the results but these would not be stored by apache.org.
        Hide
        Pablo Mariano Cibraro added a comment -

        Prototype that shows some of the discussed functionality

        Show
        Pablo Mariano Cibraro added a comment - Prototype that shows some of the discussed functionality
        Hide
        Pablo Mariano Cibraro added a comment -

        A working version of the prototype is available at this address. http://204.152.240.69/Stonehenge

        Show
        Pablo Mariano Cibraro added a comment - A working version of the prototype is available at this address. http://204.152.240.69/Stonehenge
        Hide
        Pablo Mariano Cibraro added a comment -

        Updated version of the technical specification and database model

        Show
        Pablo Mariano Cibraro added a comment - Updated version of the technical specification and database model
        Hide
        Ben Dewey added a comment -

        If you are using ASP.NET MVC2 please use the attached updated csproj file for the TestEngine.

        Show
        Ben Dewey added a comment - If you are using ASP.NET MVC2 please use the attached updated csproj file for the TestEngine.

          People

          • Assignee:
            Unassigned
            Reporter:
            Kent Brown
          • Votes:
            2 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development