Test Suite - Was: WebID enabled PoolParty - was: ISSUE-40: A glossary of the preferred terms used for talking about the WebId architecture

On 8 Nov 2011, at 00:27, Henry Story wrote:

>> 2. concerning the test-webID page.
>> 
>> i'm not going to use the PoolParty server for stuff like that. but i'm going to provide
>> an own server just for this purpose where i install tomcatWebIDRealm and protect some
>> pages and also have a page outputting the EARL test results.
> 
> And what if the code on your test server is slightly out of step with the other one? Then you'll have weird cases where people can log into one but not to there other and it will be very difficult to debug. 

On that topic I have come to the conclusion that the best way to gather the data for the test suite is to store any failure events that occurred during the verification phase itself. In the latest Scala implementation I started doing this as can be seen in this snippet of code below. See for example line 155 where I declare a list of tests, and the verified method (line 159) that simply checks  those tests to see if it contains a Verified test.

   149 class WebIDClaim(val webId: String, val key: PublicKey) {
   150 
   151 	var errors = new LinkedList[java.lang.Throwable]()
   152 
   153 	lazy val principal = new WebIdPrincipal(webId)
   154 
   155 	var tests: List[Verification] = List()
   156 
   157   private var valid = false
   158 
   159   def verified(implicit cache: WebCache): Boolean = {
   160     if (!valid) tests = verify(cache)
   161     tests.exists(v => v.isInstanceOf[Verified])
   162   }
   163   
   164   private def verify(implicit cache: WebCache): List[Verification] = {
   165     import org.w3.readwriteweb.util.wrapValidation
   166 
   167     import collection.JavaConversions._
   168     import WebIDClaim._
   169     try {
   170       return if (!webId.startsWith("http:") && !webId.startsWith("https:")) {
   171         //todo: ftp, and ftps should also be doable, though content negotiations is then lacking
   172         unsupportedProtocol::Nil
   173       } else if (!key.isInstanceOf[RSAPublicKey]) {
   174         certificateKeyTypeNotSupported::Nil
   175       } else {
   176         val res = for {
   177           model <- cache.resource(new URL(webId)).get() failMap {
   178             t => new ProfileError("error fetching profile", t)
   179           }
   180         }

 If you set up things like that, then it should in the end just be a question of a very simple serialisation of those tests to RDF or to rdfa. The nice thing is that then the answer could be absolutely correct as to why there was a failure at *that* time. After all perhaps at *that* time the network fell apart, and 5 seconds later was up again.

Now I have not yet implemented the test page in Scala with those exceptions, but I will as soon as I get a bit of time.

Henry

Social Web Architect
http://bblfish.net/