[SAGA-RG] missing(?) method reporting last modification time

[Andre Merzky]

Quoting [Thilo Kielmann] (Jun 03 2009):
> 
> On Wed, Jun 03, 2009 at 02:09:25PM +0200, Andre Merzky wrote:
> 
> > > I may want to add that also not all languages support more than the
> > > last modification time, e.g. Java only has this one...
> > 
> > Thats interesting.  Not relevant, but is that because Java
> > meets the smallest common denominator here? Simple file
> > systems such as FAT only support mtime, ususally, AFAIK.
> > 
> > Does Java have a stat call?
> 
> AFAIK, Java is considered to be an "application" programming language, as 
> opposed to systems programming languages. You can find this back e.g. in
> the stream-based file API, where random seeks are "not done" by typical
> Java applications. (read/write/seek had only been added later, but "real
> Java programmers" (-tm) don't use it ;-)
> 
> To the best of my knowledge, there is no stat either.
> 
> > > Using the attributes for the modification time (while having get_* for
> > > file size) seems odd to me. 
> > 
> > We should then move size into the attributes, too.  I agree
> > that this should be done in a consistent way.
> 
> Hmm, I must admit that I am not too familiar with the proper use of
> attributes in SAGA. I know we have them, but I never got beyond a vague
> feeling that they could be useful "somewhere"...

Things which are considered 'properties' or 'meta data' (for
whatever vague definition you want) of objects, are mostly
exposed as attributes.  Usually, changing attributes does
not directly change object state, nor trigger any remote
operation, etc.  Mostly, attributes are informational (and
thus often read-only).

As you see, the above is rather vague, and involves a lot of
handwaving.  Nevertheless, a good rule of thumb is: If a
SAGA object has a significan number of set_xxx/get_xxx
methods, which just return simple data types, the attribute
interface should be used.

An excellent example is the job_description of course, but
others are the job class (exposing memory usage, state,
walltime etc via attributes) and replicas (user defined meta
data are attached to replica entries as attributes).


> In SAGA's file (and ns_entry) classes, I can find all commonly used
> information via get_*() methods. Which information do file's provide
> via attributes??? What I mean: I cannot see a single attribute in file,
> so why now start introducing them???

The only getters on ns_entry are get_url(), get_path() and
get_name(), the only additional one in file is get_size().
Back then, we did not think this would be enough to justify
the use of the attribute interface.  

Now, if we add get_atime, get_mtime, get_ctime, and
get_btime, then it may be worth to reconsider.  If we only
go for get_mtime (as seems likely), nothing changes really,
IMHO.


> > The use of the templetized accessors is motivated by the
> > fact that we have it on task.get_result <type> () already,
> > which was actually proposed by Ceriel, and back then you
> > liked it a lot ;-)
> 
> I never (mentally) mapped task.get_result to typed attributes.
> Maybe some more background on them would help me getting a deeper
> understanding?

Well, consider the following two tasks:

  saga::task t_1 = file.get_name <saga::task::ASync> ();
  saga::task t_2 = file.get_size <saga::task::ASync> ();

get_name would return a URL, get_size returns an int.  Thus,
you need to mark the get_result() function so that the
correct type is used.  We do that with templates in C++, and
I though you'd do the same in Java?  Anyway, flags and
different names are also possible, but more difficult to
maintain, and, at least in C++, somwhat non-native:

  // method templates
  saga::url u = t_1.get_result <saga::url> ();
  int       s = t_2.get_result <int>       ();

Alternatives:

  // names
  saga::url u = t_1.get_url_result ();
  int       s = t_2.get_int_result ();

  // flags
  saga::url u = t_1.get_result (saga::type::Url);
  int       s = t_2.get_result (saga::type::Int);

So, which is it in Java?


As for attributes, that would (again in C++) look very
similar.  At the moment, we have only strings:

  std::string bufsize_s = stream.get_attribute ("BufSize");

The typed version we intent to propose would likely look
like:

  int bufsize = stream.get_attribute <int> ("BufSize");

So, would be similar to get_result().  And also similar to
task.get_object() btw, the only other templetized/typed
method in the SAGA core spec.


While we are on that topic: the spec is actually silent on
what happens if the types mismatch, e.g. if I try to call:


  // spec defines BufSize to be of type int!
  float bufsize = stream.get_attribute <float> ("BufSize"); // throws

In particular, we do not define an exception which
semantically maps that case, apart from NoSuccess (which can
always be used - that is what we do in C++ right now). 

Would people think that adding a 'IncorrectType' exception
for that reason would make sense?  It could also be resolved
on language binding level, possibly.

How does Java handle that?


Thanks, Andre.


-- 
Nothing is ever easy.