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.