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

[Andre Merzky]

Quoting [Thilo Kielmann] (Jun 02 2009):
> 
> Looks like I have opened a nice can of worms ;-)))

Yes, and I am sure you are enjoying it! ;-))


> I guess we should remind ourselves about the S of SAGA: simplicity.
> Also, the 80/20 rule might be worth reconsidering.
> 
> The last modification time is the one that (now two) applications are 
> having a use case for. (This is the 20.)

I hope you mean 80? ;-)


> In the recent dicussion, we had a few proposals for pushing these 20 
> more towards the 100...
> 
> 
> On Tue, Jun 02, 2009 at 02:10:32PM +0200, Andre Merzky wrote:
> > It seem posix defines
> > (http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html)
> > 
> >   time_t    st_atime   Time of last access. 
> >   time_t    st_mtime   Time of last data modification. 
> >   time_t    st_ctime   Time of last status change. 
> > 
> > st_birthtime/st_btime seems to be an BSD extension, AFAICS,
> > so we may want to skip this one.  It falls back to ctime
> > though, if the system does not support it.
> > 
> > This is POSIX, however, and, as Sylvain said, not many
> > middleware implementations will support the full set.
> 
> 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?


> Time of last access and of last change to me seem like bits of information
> that typically systems software (not applications) would be interested in.
> 
> Having said this, I would be in favour of limiting any addition to mtime
> (unless the other ones won't come with complexity for the user).

Fine with me.


> About the way of inclusion I am not yet decided. The simplest way for the
> user is to have something like get_mtime. (And let the Java language
> binding possibly also have an alias lastModified (matching java.io.file).)

If we limit ourself to mtime, then yes, get_mtime() may be a
good way to do it.


> 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.

Again, the whole problems comes from our decision back then
to reconsider a stat() call later - which we are doing now,
basically.


> Also, I found this whole template-based
> type casting for attributes pure overkill for SAGA and certainly out
> of scope. (The type casting should NOT be part of SAGA, but if at all
> needed be part of the application itself, or of a language-level library
> that deals with converting types.)

That is actually more a language binding issue, I think.
There may be better ways to introduce types attributes in
other languages.  Like, in Perl, the whole thing would be
build in:

  my $value = obj.get_attribute (key);

would always work. 

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 ;-)

What other options would you see for doing types attributes?


> So, what are we doing with this? Can we still smuggle this into the "errata"
> thingy???

separate mail, to keep this one 'short'...

Cheers, Andre,


-- 
Nothing is ever easy.