Hi Sergio,
I've been pulled away to work on another project so I haven't been able to actively look at the specifications you guys have been writing. Anyway, I've got some free time now so I was able to look at what you guys have done with the schema.
So my first question is, how you guys are planning to address the requirements (http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GridAustraliaRequirements
) we've given you in May 2007? I've looked at our requirements and only four of them (stories 1, 2, 3, and 6 in the link above) have been addressed by GLUE 2.0 spec (draft). All of these four requirements have already been addressed by GLUE
1.3. So from what I see, there hasn't really been anything new added to GLUE 2.0 in terms of the requirements we've asked you to add in the new schema.
Isn't the GLUE 2.0 spec already going for public comments after the next OGF? How are you planning to satisfy our requirements? GridAustralia will be very happy to contribute some of its resources just so the current draft can modified to satisfy our schema. I don't think our proposed schema is only GridAustralia specific so what we add into the specification shouldn't be an issue with anyone on this list.
I also just want to comment on story 6 of our requirements. We know that you've satisfied that requirement by adding the ModuleName attribute to the ApplicationEnvironment entity but some Grids (e.g. TeraGrid) don't use modules and JP Navarro has suggested a more generic approach (and a better way of representing this type of information) and that's by using HandleType and HandleKey attributes. See below..
<ApplicationEnvironment>
<ID>123</ID>
<Name>apache-ant</Name>
<Version>1.6.5</Version>
<HandleType>softenv</HandleType> <!-- this can have a value of modules as well -->
<HandleKey>+apache-ant-1.6.5</HandleKey> <!-- when modules is the value of type, the key will be apache-ant/1.6.5 -->
</ApplicationEnvironment>
We're happy that you've got ModuleName in there but since this is a schema that will be used by a number of grid middleware/apps around the world, we just want to do it properly and avoid tying this version of the spec to a particular environment loading package implementation like "modules".
It may be that you might not want to implement stories 9, 10, and 11 because you might think that it's just too hard to implement or you just think that there won't be any users/applications going to query for that information. If so, it would be good to get some feedback on the issues with our requirements.
Story 13 is not related to software application so we want to know how you are planning to address that in GLUE 2.0?
We also would like to hear your comments about the things we've listed under the "Glue
1.3 issues/comments" section of the GridAustraliaRequirements. I know those are not only applicable to GLUE 1.3 because I don't see the current draft of GLUE 2.0 addressing those issues yet.
Look forward to hearing from you.
Regards,
Gerson