hello, I've just checked in some changes to the deploy API -added some more tests related to initialisation (what I was working on ) -moved some tests down into the informative category, like the one that says 'you must be able to create more than one application simultaneously', as that is not actually part of the spec. I note that I dont have any tests yet for the resolve operation. that is a mistake I will have to correct. If anyone can define some tests next week,feel free to do so and stick them in the document. I am busy running the latest version of my client against the hp and the ourgrid endpoint. the NEC endpoint is not responding to me, either the firewall is blocking incoming calls or the endpoint is not there. The endpoint is successfuly demonstrating that my client stack does not implement timeouts, which is something I will have to fix. When I get back from my vacation we can start on the interop document. Something like -copy of the ogsa-dai interoperability intro -test methodology -different implementations -summary of tests (table) -test result summary (appendices containing the <junitreport> results or similar. Findings -we can demo interop between two implementations -things like WSRF, base faults and WS-N are problematic as they arent consistently implemented -SOAP stacks throw SOAPFaults when they feel like it, even if the spec mandates BaseFaults -Without a rigorous taxonomy of which fault to throw for which problem, its hard to be sure that different implementations fail for the expected reasons on any test that expectgs failure. -security. Its hard to turn security on during interop testing. -system load. testing clients can overload the server. -how do you test WS-Notification works if you are calling from behind a firewall? -discuss on what is the best model client-side. High latency links show the limitations of RPC as a metaphor, but what alternatives are there. State machine? Model the remote resources with proxy classes that cache (and refresh) properties? -unclear semantics of wsrf:Destroy in a fault tolerant world. Future enhancements to the deploy API that testing raises -the hostname hint is confusing and impossible to test. If you can't test it works, lets drop it. -it would be good to have an option on addFile to declare the URL to which a document 'pretends' to live -an alternate notification mechanism (jabber/xmpp?) that goes through firewalls. -WSRF property to list all wsrf properties on a resource Thoughts? -steve