Globus issues present and future

[Ivan R. Judson]

Just an update, Bob can chime in if he chooses, Tom too, but I wanted to
give you guys a heads up.

We're currently not upgrading to the latest globus code because it's
unconfirmed to work (they did minimal testing in their environment, but it's
not clear if they tested with pyGlobus or not -- even though we put the two
parties together and said, "test this so we can use it").

It's looking like the summer will be hell too. 100% of the XIO module has to
be ported to windows, plus, 100% of the overall toolkit is being rewritten
to handle this new wsrf effort announced at globus world. What that means is
that we are not planning on moving from GT2.4.3 (linux) and (this release
our winglobus code) [next release perhaps gaffaney code if it's tested by
then]. This constrains us to an older pyGlobus (we're working on that issue
as we speak).

The real problem here is that windows is clearly not a supported platform,
although effort has been made to make it work. Bob Gaffaney has done a good
job, that should not be misunderstood.

We're not going to upgrade all of our users to entirely new code that hasn't
been out there getting the kinks worked out 2 times this year. That's
directly counter to our need to stabilize the software out there and make
the community happy.

We've been chatting about how much effort it would be to do our own proxy
creation, verification and management and separating ourselves from the GT
altogether. It's not clear what advantage (other than political we have from
using it), they are gaining a helluva a lot more advantage by us using it
than we are. 

There are other various concerns, but they're details of the problem. The
main problem is that the GT isn't end-user code and it isn't packaged for
developers to be able to do anything with it. Where does that leave us?
Doing *a lot* of work that we shouldn't be doing.

--Ivan

PS -- forward this as you see fit