[SAGA-RG] Context and Session thoughts

[Andre Merzky]

Most certainly :-)



Quoting [Steve Fisher] (Feb 25 2009):
> Date: Wed, 25 Feb 2009 13:01:32 +0000
> Subject: Re: [SAGA-RG] Context and Session thoughts
> From: Steve Fisher <dr.s.m.fisher at gmail.com>
> To: Ceriel Jacobs <ceriel at cs.vu.nl>
> Cc: Andre Merzky <andre at merzky.net>, SAGA RG <saga-rg at ogf.org>
> 
> Perhaps this is something we could discuss next week in Catania
> 
> 2009/2/25 Ceriel Jacobs <ceriel at cs.vu.nl>:
> > Andre Merzky wrote:
> >>
> >> Quoting [Ceriel Jacobs] (Feb 25 2009):
> >>>
> >>> Andre Merzky wrote:
> >>>>
> >>>> Quoting [Ceriel Jacobs] (Feb 20 2009):
> >>>
> >>> (who quoted Steve Fisher)
> >>>>>>
> >>>>>> The user can also create a context with a type known to him and to the
> >>>>>> implementation. He may need to set attributes of this context before
> >>>>>> it can be used. The implementation must not modify any attributes -
> >>>>>> though the constructor may set attributes to sensible defaults which
> >>>>>> can then be modified by the user.
> >>>>>>
> >>>>>> The set_defaults call should *not* be in the spec - it is purely an
> >>>>>> implementation thing.
> >>>>>
> >>>>> I think I agree with that. It is a pity that the Context
> >>>>> constructor has a default value "" for the context type.
> >>>>> IMHO, the Type attribute should only have read access and be set by
> >>>>> the Context constructor, which should then also call set_defaults,
> >>>>> which then does not have to be in the API.
> >>>>
> >>>> Calling set_defaults() in the c'tor breaks.  That was
> >>>> actually in the spec at some point, but:
> >>>>
> >>>>  saga::context c ("globus");
> >>>>  c.set_attribute ("UserProxy", "/tmp/non-default-proxy.x509");
> >>>>  c.set_defaults  ();
> >>>
> >>> Well, calling set_defaults in the constructor IS in the specs, at least
> >>> it is in the 1.0 version, which is still the official version, is it not?
> >>> There, it sais in the Notes: if a type is given, then the CONSTRUCTOR
> >>> internally calls set_defaults().
> >>
> >> Right - the errata remove that call.
> >>
> >>
> >>>> The c'tor would throw NoSuccess if no default globus proxy
> >>>> exists.  Then, how would you create a globus context which
> >>>> points to a non-default proxy location, like above?
> >>>
> >>> I don't know that the c'tor would throw NoSuccess. Maybe a default
> >>> UserProxy file does not exist, but is set_defaults() the right
> >>> time to check?
> >>
> >> When else can you check?  On setting the attribute would be
> >> an option - but throwing there would confuse: the exceptions
> >> defined on set_attribute are attribute related, not related
> >> to the semantics of the context.  One could also check
> >> internally at the first time the context is being used, but
> >> then it is hard to predict on API level when that exception
> >> will come, and again it is probably in a context unrelated
> >> to the, uhm, context (pun unintented).  So, set_defaults
> >> provides a good opportnity to flag any inconsistencies.
> >
> > I would indeed check the first time the context is being used.
> > I don't think it is hard to predict on API level when an exception
> > will come, because virtually all methods can throw a
> > corresponding exception. Also, set_defaults may possibly detect
> > SOME inconsistencies, but certainly not all.
> >
> >>>> Yes, one could argue if an empty type on context creation
> >>>> makes sense, or if one should mandate a valid string.  Given
> >>>> that an empty string is a 'valid' string in most languages,
> >>>> that is not much different from other invalid strings like
> >>>> 'klopus'.  We have defined error conditions for calling
> >>>> set_defaults() on invalid context attributes.  I don't think
> >>>> that this is a big problem at the moment?
> >>>
> >>> I guess there is a difference between "" and "klopus" in that
> >>> "" is IMHO supposed to mean that the Type is not yet specified,
> >>> whereas "klopus" specifies a Type, on which the constructor
> >>> will call set_defaults(), which will probably cause an exception.
> >>
> >> Again, set_defaults() in the c'tor cannot work - you could
> >> never create a context with a non-default location for the
> >> globus proxy file.
> >
> > Indeed, not if you want set_defaults to do all the things you
> > describe. But I don't think set_defaults is the right place.
> > If you set some attributes explicitly, like "UserProxy",
> > or "UserId", or "UserPass", there is no check either. In general,
> > the first time you notice that something is wrong is when you
> > try to actually use the context. I don't see why this should be
> > any different if you use set_defaults. For instance, you could
> > create an ftp context with perfectly reasonable default values
> > for UserId and UserPass, but if you then connect to an ftp server
> > that does not allow anonymous access, you still have a problem.
> > So, I think a cleaner design would be to not have set_defaults,
> > and to have the context constructor set some reasonable default values
> > (if a Type is specified). It would then be up to the user to make sure
> > that the default values actually work.
> >
> > Cheers,         Ceriel
> >



-- 
Nothing is ever easy.