[SAGA-RG] Context and Session thoughts

Andre Merzky andre at merzky.net
Wed Feb 25 09:52:09 CST 2009


Quoting [Ceriel Jacobs] (Feb 25 2009):
> Date: Wed, 25 Feb 2009 15:49:18 +0100
> From: Ceriel Jacobs <ceriel at cs.vu.nl>
> To: Andre Merzky <andre at merzky.net>
> CC: Steve Fisher <dr.s.m.fisher at gmail.com>, SAGA RG <saga-rg at ogf.org>
> Subject: Re: [SAGA-RG] Context and Session thoughts
> 
> Andre Merzky wrote:
> >Quoting [Ceriel Jacobs] (Feb 25 2009):
> >>> saga::context c ("globus");
> >>>
> >>> c.set_defaults ();
> >>>
> >>> // get info about default globus proxy
> >>> std::cout << c.get_attribute ("LifeTime");
> >>> std::cout << c.get_attribute ("UserID");
> >>> std::cout << c.get_attribute ("VO");
> >>>
> >>>without set_defaults, it is totally undefined when these
> >>>attributes are available.
> >>After calling the constructor? As would be the case for
> >>the SAGA 1.0 specs?
> >
> >As said: calling set_defaults in the constructor cannot
> >possibly stay in the spec: that breaks in those cases where
> >set_defaults would throw.  If the c'tor then throws for a
> >given type, you can't create any context of that type _at_
> >_all_.
> 
> That's one reason why I think set_defaults should not be in the API,
> and should not throw. Instead, the constructor should set suitable
> defaults, if it can. If it does not recognize the Type, it can throw
> an exception, but only then. Other errors will turn up when
> the context is used.

Ah, got it now I think, thanks for bearing with me.  So,
setting the defaults in the c'tor would not throw anymore.

The following would then still not work:

  saga::context c ("globus");
  c.set_attribute ("UserProxy", "/tmp/<F2>does-not-exist");
 
  // get info about default globus proxy
  std::cout << c.get_attribute ("LifeTime");
  std::cout << c.get_attribute ("UserID");
  std::cout << c.get_attribute ("VO");
 
but that might be acceptable.


> >>>One can very likely achieve a consistent API w/o
> >>>set_defaults, by defining a couple of semantic changes
> >>>which address the issues above explicitely, no doubt.  I
> >>>just don't think (a) that this is justified, and (b) that
> >>>this would really simplify matters.
> >>But I think the CURRENT changes with respect to SAGA 1.0
> >>are much bigger.
> >
> >Hmm, you mean the ones we have in the errata I assume?  Yes,
> >some of them are bigger.  However, they are there to fix
> >errors.
> 
> No, I mean the change that set_defaults is not to be called anymore
> from the constructor. That is quite a big change, that may affect
> all SAGA applications. I don't know if SAGA applications usually
> call set_defaults(), since SAGA 1.0 specifies that it is called
> from the constructor, if a Type is specified.

Well, for those applications which _do_ call set_defaults()
anywhere, removing that call would be an equally big change
- so that does not help us to decide either way I guess...


> >> O well, I think I have vented my opinion enough for now
> >> ...
> 
> > Hmm, would you mind if we discuss that on the phone?  I
> > agree that we are running in circles somehow, but I would
> > like to get the discussion to a conclusion one way or the
> > other, instead of leaving it open...  Can I call you
> > somewhere?
> 
> Of course you can call me, you know the number (since it was
> yours as well for a while :-)

You sincerely overestimate my memory, and my ability to keep
track of phone numbers! :-)  But anyway, found it online.

> But this is not just between you and me,
> although it may seem that way now. We both live in European time:-)
> Maybe this discussion prompts some more opinions.

I would be delighted to hear them!  I am known to be stubborn
unless there are at least two opposing opinions (*) ;-)

Cheers, Andre


(*) This is an endless source of grief for my wife, you see?  :-P


-- 
Nothing is ever easy.


More information about the saga-rg mailing list