Notes from the meeting on 5/31/2006
Attendees: Satish (NEC), Flavio, Guilherme (UFCG), Dejan (HP) Agenda: 1. Update: UFCG: no significant progress with component model because they missing files from others, from everyone. ACTION item: get files from Satish, Steve, and Stuart, so that UFCG can make some progress. (Satish: some of these cases, such as switch and delegate still haven't been implemented in the parser, so right now he does not have these files, will probably work on these this week and send them to Flavio. Others (STUART AND STEVE): PLEASE REPLY BY EMAIL WHEN YOU WILL PROVIDE THE FILES). Flavio will explicitly request these files. Guilherme testing against the NEC endpoint broke again, not sure what is it about. The interval was 2 minutes. Satish requested to get the sample tests and possibly trace. Satish was testing from inside and did not get problems. NEC: Wrt UFCG, he did deployment test using CDL that Flavio sent a few weeks ago, is trying to reproduce the problems and it is failing but still does not understand what it is. The problem is with not being able to deployment components on each other's components. Deployment APIs are 75% on HP endpoint, but not wrt component model. Asked Steve with how to resolve the issue with him not being able to talk to other endpoints, but still didn't get response. 2. We received feedback on the CDL spec and Jun should take action on it. Jun, can you please let us know approximately when you will be able to address the questions raised. 3. EVERYONE: PLEASE TRY TO ATTEND NEXT MEETING. WE ARE CLOSE TO OUR MILESTONE TO COMPLETE TESTING SO THAT WE CAN START WRITING INFORMAL DOCUMENT SUMMARIZING INTEROPERABILITY! Thanks, Dejan.
-----Original Message----- From: owner-cddlm-wg@ggf.org [mailto:owner-cddlm-wg@ggf.org] On Behalf Of Milojicic, Dejan S (HP Labs) Sent: 31 May 2006 14:18 To: cddlm-wg@ggf.org Subject: [cddlm] Notes from the meeting on 5/31/2006
Attendees: Satish (NEC), Flavio, Guilherme (UFCG), Dejan (HP)
Agenda:
1. Update:
UFCG: no significant progress with component model because they missing files from others, from everyone. ACTION item: get files from Satish, Steve, and Stuart, so that UFCG can make some progress. (Satish: some of these cases, such as switch and delegate still haven't been implemented in the parser, so right now he does not have these files, will
Just to let you all know that Steve is on vacation this week, but is back on Monday. He won't be able to provide you with the files you need until then. Congratulations on the excellent progress that you are making. Regards, Peter probably
work on these this week and send them to Flavio. Others (STUART AND STEVE): PLEASE REPLY BY EMAIL WHEN YOU WILL PROVIDE THE FILES). Flavio will explicitly request these files. Guilherme testing against the NEC endpoint broke again, not sure what is it about. The interval was 2 minutes. Satish requested to get the sample tests and possibly trace. Satish was testing from inside and did not get problems.
NEC: Wrt UFCG, he did deployment test using CDL that Flavio sent a few weeks ago, is trying to reproduce the problems and it is failing but still does not understand what it is. The problem is with not being able to deployment components on each other's components. Deployment APIs are 75% on HP endpoint, but not wrt component model. Asked Steve with how to resolve the issue with him not being able to talk to other endpoints, but still didn't get response.
2. We received feedback on the CDL spec and Jun should take action on it. Jun, can you please let us know approximately when you will be able to address the questions raised.
3. EVERYONE: PLEASE TRY TO ATTEND NEXT MEETING. WE ARE CLOSE TO OUR MILESTONE TO COMPLETE TESTING SO THAT WE CAN START WRITING INFORMAL DOCUMENT SUMMARIZING INTEROPERABILITY!
Thanks,
Dejan.
Milojicic, Dejan S (HP Labs) wrote:
Attendees: Satish (NEC), Flavio, Guilherme (UFCG), Dejan (HP)
Agenda:
1. Update:
UFCG: no significant progress with component model because they missing files from others, from everyone. ACTION item: get files from Satish, Steve, and Stuart, so that UFCG can make some progress. (Satish: some of these cases, such as switch and delegate still haven't been implemented in the parser, so right now he does not have these files, will probably work on these this week and send them to Flavio. Others (STUART AND STEVE): PLEASE REPLY BY EMAIL WHEN YOU WILL PROVIDE THE FILES). Flavio will explicitly request these files. Guilherme testing against the NEC endpoint broke again, not sure what is it about. The interval was 2 minutes. Satish requested to get the sample tests and possibly trace. Satish was testing from inside and did not get problems.
I cant reach the NEC endpoint from behind my firewall; can anyone else see it? I think the proxy server here is complicating the reporting, because when I telnet from a public site I get a connection but no response
telnet cddlm.nec-labs.com 9090 Trying 138.15.110.100... Connected to cddlm.nec-labs.com. Escape character is '^]'. GET /cddlm/services/portal HTTP/1.0
...and I can sit there indefinately waiting for a reply. Indeed, my test client does sit there indefinately, which is a bug somewhere in apache httpclient. Actually, the UFCG epr isnt reachable either, even when I ssh to a site beyond the firewall and try and telnet to port 8080
uname -a FreeBSD minotaur.apache.org 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Thu May 11 11:50:25 PDT 2006 root@minotaur.apache.org:/usr/obj/usr/src/sys/SMP-turbo i386
telnet cddlm.lsd.ufcg.edu.br 8080 Trying 150.165.15.37... telnet: connect to address 150.165.15.37: Connection refused telnet: Unable to connect to remote host
NEC: Wrt UFCG, he did deployment test using CDL that Flavio sent a few weeks ago, is trying to reproduce the problems and it is failing but still does not understand what it is. The problem is with not being able to deployment components on each other's components. Deployment APIs are 75% on HP endpoint, but not wrt component model. Asked Steve with how to resolve the issue with him not being able to talk to other endpoints, but still didn't get response.
1. I need to be able to talk to the endpoints 2. I can then use axis tcpmon to get a trace record of the message that is sent and the fault that is sent back. 3. I can send the record of the message to the other endpoint to see if they can replicate the problem. If we can find out what line is throwing the real fault, its possible to track down the underlying cause, which is possible/probable that muse and I have different misinterpretations of the WSRF and WSA specifications. I will have to workaround whatever they are, regardless of whose fault it is.
2. We received feedback on the CDL spec and Jun should take action on it. Jun, can you please let us know approximately when you will be able to address the questions raised.
Is this the ongoing discussion about importing into namespaces?
3. EVERYONE: PLEASE TRY TO ATTEND NEXT MEETING. WE ARE CLOSE TO OUR MILESTONE TO COMPLETE TESTING SO THAT WE CAN START WRITING INFORMAL DOCUMENT SUMMARIZING INTEROPERABILITY!
I've been on holiday. -steve
Steve Loughran wrote:
Milojicic, Dejan S (HP Labs) wrote:
Attendees: Satish (NEC), Flavio, Guilherme (UFCG), Dejan (HP)
Agenda:
1. Update: UFCG: no significant progress with component model because they missing files from others, from everyone. ACTION item: get files from Satish, Steve, and Stuart, so that UFCG can make some progress. (Satish: some of these cases, such as switch and delegate still haven't been implemented in the parser, so right now he does not have these files, will probably work on these this week and send them to Flavio. Others (STUART AND STEVE): PLEASE REPLY BY EMAIL WHEN YOU WILL PROVIDE THE FILES). Flavio will explicitly request these files. Guilherme testing against the NEC endpoint broke again, not sure what is it about. The interval was 2 minutes. Satish requested to get the sample tests and possibly trace. Satish was testing from inside and did not get problems.
I cant reach the NEC endpoint from behind my firewall; can anyone else see it?
I think the proxy server here is complicating the reporting, because when I telnet from a public site I get a connection but no response
telnet cddlm.nec-labs.com 9090 Trying 138.15.110.100... Connected to cddlm.nec-labs.com. Escape character is '^]'. GET /cddlm/services/portal HTTP/1.0
...and I can sit there indefinately waiting for a reply. Indeed, my test client does sit there indefinately, which is a bug somewhere in apache httpclient.
Actually, the UFCG epr isnt reachable either, even when I ssh to a site beyond the firewall and try and telnet to port 8080
uname -a FreeBSD minotaur.apache.org 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Thu May 11 11:50:25 PDT 2006 root@minotaur.apache.org:/usr/obj/usr/src/sys/SMP-turbo i386
telnet cddlm.lsd.ufcg.edu.br 8080 Trying 150.165.15.37... telnet: connect to address 150.165.15.37: Connection refused telnet: Unable to connect to remote host
It is now online! Sorry!
NEC: Wrt UFCG, he did deployment test using CDL that Flavio sent a few weeks ago, is trying to reproduce the problems and it is failing but still does not understand what it is. The problem is with not being able to deployment components on each other's components. Deployment APIs are 75% on HP endpoint, but not wrt component model. Asked Steve with how to resolve the issue with him not being able to talk to other endpoints, but still didn't get response.
1. I need to be able to talk to the endpoints
2. I can then use axis tcpmon to get a trace record of the message that is sent and the fault that is sent back.
3. I can send the record of the message to the other endpoint to see if they can replicate the problem. If we can find out what line is throwing the real fault, its possible to track down the underlying cause, which is possible/probable that muse and I have different misinterpretations of the WSRF and WSA specifications. I will have to workaround whatever they are, regardless of whose fault it is.
2. We received feedback on the CDL spec and Jun should take action on it. Jun, can you please let us know approximately when you will be able to address the questions raised.
Is this the ongoing discussion about importing into namespaces?
3. EVERYONE: PLEASE TRY TO ATTEND NEXT MEETING. WE ARE CLOSE TO OUR MILESTONE TO COMPLETE TESTING SO THAT WE CAN START WRITING INFORMAL DOCUMENT SUMMARIZING INTEROPERABILITY!
I've been on holiday.
-steve
-- Flavio Roberto Santos Undergraduate student at Universidade Federal de Campina Grande OurGrid Team Member - www.ourgrid.org My webpage - http://www.ourgrid.org/~flavio -- "As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality." -- Albert Einstein
I propose two modifications on the spec to address issues we have discussed. I hope this will not be a huge change... [1] Remove "import with namespace specified" from the spec. This has been introduced to address namespace conflict at the user side. However, it turned out that this introduces complication we did not initially expect, as pointed out in the discussion with Steve and Rakesh. Since namespace itself is meant to address name conflict, why don't we let namespace work on that. Instead of making it more complicated with patches, I propose to remove cdl:import/@namespace from the spec and add a "guidance" (or best practices) as follows: -- "When the provider publishes a CDL document for component description, which is likely to be combined with ones from different providers, the provider SHOULD use a unique namespace for the toplevel elements." The user side should stop worrying about importing something into a new namespace at his own risk and start blaming the careless provider who published conflicting names. [2] On prototype resolution, treat a reference and a value interchangeably: On prototype resolution, (1) a value reference (a pair of @cdl:refroot and @cdl:ref) is overridden by either a value reference or a property value (child nodes); (2) a property value (child nodes) is overridden by either a value reference or a property value. -- I will be attending tomorrow's call to discuss. Best Regards, Jun Tatemura
Let me give examples on proposal [2]: <cdl:configuration> <a> <b cdl:ref="/c"/> <c>10</c> </a> </cdl:configuration> <cdl:system> <test cdl:extends="a"> <b>20</b> </test> </cdl:system> resolved as <test> <b>20</b> <c>10</c> </test> --- <cdl:configuration> <a> <b cdl:refroot="e" cdl:ref="/c"/> <c>10</c> <d>20</d> </a> <e> <c>30</c> <d>40</d> </e> </cdl:configuration> <cdl:system> <test cdl:extends="a"> <b cdl:ref="/d"> </test> </cdl:system> resolved as <test> <b>20</b> <c>10</c> <d>20</d> </test> --- <cdl:configuration> <a> <b>10</b> <c>20</c> </a> </cdl:configuration> <cdl:system> <test cdl:extends="a"> <b cdl:ref="/c"/> </test> </cdl:system> resolved as <test> <b>20</b> <c>20</c> </test> Jun Tatemura wrote:
I propose two modifications on the spec to address issues we have discussed. I hope this will not be a huge change...
[1] Remove "import with namespace specified" from the spec.
This has been introduced to address namespace conflict at the user side. However, it turned out that this introduces complication we did not initially expect, as pointed out in the discussion with Steve and Rakesh. Since namespace itself is meant to address name conflict, why don't we let namespace work on that. Instead of making it more complicated with patches, I propose to remove cdl:import/@namespace from the spec and add a "guidance" (or best practices) as follows:
-- "When the provider publishes a CDL document for component description, which is likely to be combined with ones from different providers, the provider SHOULD use a unique namespace for the toplevel elements."
The user side should stop worrying about importing something into a new namespace at his own risk and start blaming the careless provider who published conflicting names.
[2] On prototype resolution, treat a reference and a value interchangeably:
On prototype resolution, (1) a value reference (a pair of @cdl:refroot and @cdl:ref) is overridden by either a value reference or a property value (child nodes); (2) a property value (child nodes) is overridden by either a value reference or a property value.
-- I will be attending tomorrow's call to discuss.
Best Regards, Jun Tatemura
After we reach an agreement on the issues (to which I have proposed resolutions), I will take approximately one week to incorporate everything (including public comments) into a new revision. Best Regards, Jun Milojicic, Dejan S (HP Labs) wrote:
2. We received feedback on the CDL spec and Jun should take action on it. Jun, can you please let us know approximately when you will be able to address the questions raised.
participants (5)
-
Flávio Roberto Santos / OurGrid Project -
Jun Tatemura -
Milojicic, Dejan S (HP Labs) -
Steve Loughran -
Toft, Peter