[SAGA-RG] SAGA questions ...

[Andre Merzky]

Hi Ceriel, 

I Cc the mailing list as it would be good to include others
in the language binding discussion...

Quoting [Ceriel Jacobs] (Oct 18 2007):
> 
> Hi Andre,
> 
> I am now starting to implement some of the SAGA stuff on top of javaGAT,
> and have a couple of new questions, but am also leaving on holiday for
> a week (until Oct 29), so I don't need an immediate answer. I will be
> in a hurry when I get back, though ;-)
> Anyway, here are the questions:
> 
> 1. monitoring/metrics:
>    The metrics are supposed to do callbacks. These callbacks take
>    a.o. a Monitorable and a Context. I haven't got a clue where to
>    get them from. I would expect them to live in the metric,
>    but they don't. At least, they are not provided in the constructor
>    of the metric (see the SAGA specs, page 123 in my version).They are
>    also not provided in the fire() method. So, where to get them from?

The use case is as follows:

------------------------------------------------------------------
A)
  saga::job j = js.run_job (...);

  j.add_callback ("state", my_cb);

  j.wait ();
------------------------------------------------------------------
B)
  saga::job j = js.run_job (...);

  saga::metric m = j.get_metric ("state");
  m.add_callback (my_cb);

  j.wait ();
------------------------------------------------------------------

In both cases, the metric 'knows' from what monitorable it
comes from.  The metric should store that internally, and
give it to the cb on invocation.

The direct constructor for the metric is actually rarely
needed - the only use case for that is, at the moment, if an
application registers an own metric:
------------------------------------------------------------------
  saga::job_self self = js.get_self ();
  saga::metric   m ("test_metric", ...);
  self.add_metric (m);
------------------------------------------------------------------

In this case, the metric knows the monitorable as well: its
self.  If a metric is just created, and never attached to a
monitorable, it can never change, so the callback cannot be
called, so you don't need the monitorable ;-)

About the context: that context is supposed to represent the
_remote_ entity, the one who caused the metric to change.
For example, if a job state changes to failed, the context
should be the one representing the credential of the job
service who is reporting that state change.

That context will often not be available - in that case, an
'Unknown' context is returned.  The main use case is
actually for streams, where the remote party can be
authenticated/authorized to create a connection.


> 2. attributes:
>    What exactly does "removable" mean? A complete removal of the
>    attribute, so that you cannot specify a new value for it later on,
>    or just removal of any assigned value?

The first one: it can be removed.  An example is an
attribute on logical files: those are all removable
(logical_files have no default attributes).


> 3. attributes:
>    What exactly should listAttributes list? All attributes that
>    have a value? Or just all supported attributes? Or all
>    implemented attributes?

All attributes that are available, i.e. where I can call
get_attribute() upon.  An empty value can be valid,  so
empty attributes should also be listed.  All attributes
which are listed as non-optional in the spec, and are
non-removeable (none of the listed one is removable at the
moment) must be listed, potentially with their default
values.  Optional attribs which are not supported by that
implementation should not be listed.

Does that make sense?

Cheers, Andre.


> Cheers, Ceriel.



-- 
No trees were destroyed in the sending of this message, however,
a significant number of electrons were terribly inconvenienced.