[OGSA-BES-WG] Tracker Resolution Descriptions

Thu Sep 7 09:23:56 CDT 2006

Tom is right - we choose to be agnostic to avoid the conflict - not because
we thought it was a good idea. My only concern with re-opening this can of
worms is the additional delay. I am personally not against using the merged
model - though I certainly cannot claim to speak for the group. 

W.R.T. the merged specification I have a proposal. Perhaps we should get the
document to public comment NOW with a comment in the document that we are
going over to the merged model - and solicit feedback on that. We have got
to get this document into public comment or we will spin endlessly. 

A

> -----Original Message-----
> From: ogsa-bes-wg-bounces at ogf.org [mailto:ogsa-bes-wg-bounces at ogf.org]
> On Behalf Of Maguire_Tom at emc.com
> Sent: Wednesday, September 06, 2006 2:26 PM
> To: ogsa-bes-wg at ogf.org
> Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
> 
> But the only reason we were resource agnostic was because there was
> conflict.  We didn't choose to be resource agnostic just because it
> seemed
> like a good idea (did we?).  There certainly was (are) some who argue
> against any resource model (eg. Purely stateless services), vs those who
> would encode some resource identity into an addressing scheme (WS-RF and
> WS-Transfer).  In the end most (all) of this discussion is about whether
> we
> should encode identity of state in parameters in the body of the request
> or
> we should encode identity of state in the headers not whether there is
> state
> or not.
> Personally, I think that WS-Addressing makes all of this pretty moot,
> but if
> shouting at the wind makes us feel better, feel free....
> 
> Tom
> 
> _______________________________________________
> Tom Maguire
> +1(845) 729-4806
> 
> 
> -----Original Message-----
> From: ogsa-bes-wg-bounces at ogf.org [mailto:ogsa-bes-wg-bounces at ogf.org]
> On
> Behalf Of Andrew Grimshaw
> Sent: Wednesday, September 06, 2006 1:48 PM
> To: 'Mail list for ogsa-bes-wg working group'
> Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
> 
> I agree with Chris - I never thought of this as a WS-RF versus anything
> else
> issue - more an issue with trying to be resource model agnostic.
> 
> A
> 
> > -----Original Message-----
> > From: ogsa-bes-wg-bounces at ogf.org [mailto:ogsa-bes-wg-bounces at ogf.org]
> > On Behalf Of Christopher Smith
> > Sent: Wednesday, September 06, 2006 1:17 PM
> > To: Mail list for ogsa-bes-wg working group
> > Cc: ogsa-bes-wg at ggf.org
> > Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
> >
> > Characterizing this issue as WS-RF vs WS-Transfer is misleading. I
> can't
> > recall any discussions within this group where anybody advocated doing
> a
> > WS-Transfer rendering for the BES interface. Well ... other than the
> WS-
> > RF
> > proponents who wrongly assumed that because some (like myself) were
> > against
> > the use of WS-RF, that must mean we were in favour of WS-Transfer. I
> > also
> > don't recall anybody advocating operations for modification, etc such
> as
> > defined within WS-Transfer. To me this is a discussion of a resource
> > modelling approach (built on WS-RF) vs a non resource modelling
> approach.
> >
> > My main reason for not wanting to make use of one of the resource
> > modelling
> > approaches has to do with the burden of implementation. If Platform
> buys
> > into one of these resource models, we no longer have to implement one
> > simple
> > spec and test compliance of that specification, but we need to
> implement
> > and
> > test compliance on a suite of specifications, for (in my opinion) no
> > extra
> > benefit. You might say that once you've implemented a resource
> modelling
> > suite of specifications, you can use it over and over and thus
> amortize
> > the
> > cost of this implementation. But even at a small cost, it's not one
> that
> > I'm
> > willing to take, as the implementation of standards specifications is
> > one
> > feature in a sea of features that we implement from product release to
> > product release.
> >
> > -- Chris
> >
> >
> >
> > On 06/9/06 07:56, "Peter G. Lane" <lane at mcs.anl.gov> wrote:
> >
> > > If it's about fear of reopening the dialog, then I'd appreciate if
> > someone
> > > could at least add
> > > comments to the two trackers addressing the issues raised.
> > >
> > > Ian can push for reopening this particular issue if he wants; but I
> > just want
> > > to know why we're
> > > advocating WS-Transfer in spirit if not in name, and why aggregation
> > of
> > > resource attributes is not a
> > > concern to anyone else. As long as someone has a reason for these
> > issues that
> > > I raised in the
> > > tracker, I'm fine. I don't expect to get everything to go my way,
> and
> > I'm open
> > > to being convinced of
> > > alternate points of view. I just don't like being ignorant,
> especially
> > when
> > > I'll have to implement
> > > the spec someday.
> > >
> > > On the other hand, if nobody has a good answer for the issues, I
> think
> > Ian is
> > > perfectly valid in
> > > asking for it to be reopened as apparently the issues weren't
> actually
> > > addressed as they should have
> > > been.
> > >
> > > Peter
> > >
> > > Mark Morgan wrote:
> > >> Well, I guess the thing that confuses me is whether or not it is
> SOP
> > to
> > >> re-open an issue that was discussed previously because a new person
> > has
> > >> re-raised that issue.  I'll bow to whatever the majority thinks is
> > best of
> > >> course, but it seems to me that you can't reopen an issue everytime
> a
> > new
> > >> person re-raises it or you risk the possibility of continuously
> > cycling on
> > >> it.  New information should always be considered, but if an issue
> > gets
> > >> re-raised that has already been discussed fully and voted on, then
> it
> > >> doesn't make sense to re-discuss it.  Just my 2 cents worth...
> > >>
> > >> -Mark
> > >>
> > >>> -----Original Message-----
> > >>> From: ogsa-bes-wg-bounces at ogf.org
> > >>> [mailto:ogsa-bes-wg-bounces at ogf.org] On Behalf Of Ian Foster
> > >>> Sent: Tuesday, September 05, 2006 9:39 PM
> > >>> To: Mail list for ogsa-bes-wg working group; 'Mail list for
> > >>> ogsa-bes-wg working group'; ogsa-bes-wg at ggf.org
> > >>> Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
> > >>>
> > >>> Mark:
> > >>>
> > >>> I guess that I am asking that we re-open the issue, then.
> > >>>
> > >>> Ian.
> > >>>
> > >>> At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote:
> > >>>
> > >>>
> > >>> I'm not sure what level of "addressing" is meant here, but my
> > >>> recollection/belief was that it was addressed in the
> > >>> group in so much as the
> > >>> topic was discussed at the last face-to-face and that
> > >>> the appearance of the
> > >>> GetAttributesDocument was the result of that
> > >>> discussion.  We haven't as a
> > >>> group discussed the email that Peter sent out yet but
> > >>> it is my belief that
> > >>> doing so is essentially a rehash of discussions previously had.
> > >>>
> > >>> -Mark
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: ogsa-bes-wg-bounces at ogf.org
> > >>>> [mailto:ogsa-bes-wg-bounces at ogf.org] On Behalf Of Ian Foster
> > >>>> Sent: Tuesday, September 05, 2006 1:42 PM
> > >>>> To: Mail list for ogsa-bes-wg working group;
> > >>> ogsa-bes-wg at ggf.org
> > >>>> Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
> > >>>>
> > >>>> Has Peter's comment been discussed?
> > >>>>
> > >>>> He advocates (I believe) that we should not include the
> > >>>> GetAttributesDocument operation. Instead, any particular BES
> > >>>> should choose (if they wish) to provide access to attributes
> > >>>> via an appropriate resource model-specific operations.
> > >>>>
> > >>>> * A WS-Transfer-based BES would use GET
> > >>>> * A WSRF-based BES would use WS-ResourceProperties
> > >>>> * A resource-model-free BES might define a
> > >>>> GetAttributesDocument operation
> > >>>> * etc.
> > >>>>
> > >>>> This seems a good proposal to me.
> > >>>>
> > >>>> Ian.
> > >>>>
> > >>>> At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
> > >>>>
> > >>>>
> > >>>>       2) Why are we still essentially advocating
> > >>>> WS-Transfer's attribute model by having the
> > >>>> GetAttributesDocument operation? In my opinion it is not
> > >>>> necessary for minimal interop, and makes WS-Transfer's Get
> > >>>> operation redundant. Is part of the problem that we haven't
> > >>>> defined any interop standards yet?
> > >>>>
> > >>>>
> > >>> _______________________________________________________________
> > >>>> Ian Foster -- Weblog: http://ianfoster.typepad.com
> > >>> <http://ianfoster.typepad.com/>
> > >>>> <http://ianfoster.typepad.com/> Computation Institute:
> > >>>> www.ci.uchicago.edu <http://www.ci.uchicago.edu/>
> > >>> <http://www.ci.uchicago.edu/>  &
> > >>>> www.ci.anl.gov <http://www.ci.anl.gov/>
> > >>> <http://www.ci.anl.gov/>
> > >>>> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
> > >>>> Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
> > >>>> Tel: +1 630 252 4619 --- Globus Alliance:
> > >>> www.globus.org <http://www.globus.org/>
> > >>>> <http://www.globus.org/>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>> --
> > >>>  ogsa-bes-wg mailing list
> > >>>  ogsa-bes-wg at ogf.org
> > >>>  http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
> > >>>
> > >>> _______________________________________________________________
> > >>> Ian Foster -- Weblog: http://ianfoster.typepad.com
> > >>> <http://ianfoster.typepad.com/> Computation Institute:
> > >>> www.ci.uchicago.edu <http://www.ci.uchicago.edu/>  &
> > >>> www.ci.anl.gov <http://www.ci.anl.gov/>
> > >>> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
> > >>> Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
> > >>> Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org
> > >>> <http://www.globus.org/>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >> --
> > >>   ogsa-bes-wg mailing list
> > >>   ogsa-bes-wg at ogf.org
> > >>   http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
> > >>
> > >
> > > --
> > >   ogsa-bes-wg mailing list
> > >   ogsa-bes-wg at ogf.org
> > >   http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
> >
> > --
> >   ogsa-bes-wg mailing list
> >   ogsa-bes-wg at ogf.org
> >   http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
> 
> --
>   ogsa-bes-wg mailing list
>   ogsa-bes-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-bes-wg