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

[Thilo Kielmann]

Looks like I have opened a nice can of worms ;-)))

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

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

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

Using the attributes for the modification time (while having get_* for
file size) seems odd to me. 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.)


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

Regards,


Thilo

> 
> Best, Andre.
> 
> 
> > 2009/6/2 Andre Merzky <andre at merzky.net>:
> > >
> > > Dear Sylvain,
> > >
> > > Quoting [Sylvain Reynaud] (Jun 01 2009):
> > >>
> > >> Andre Merzky a écrit :
> > >> >So, would something like
> > >> >
> > >> >  get_atime ()
> > >> >  get_mtime ()
> > >> >  get_ctime ()
> > >> >  get_btime ()
> > >> >
> > >> >work for you folx?  I realize that this differs from what
> > >> >Sylvain's group added to JSAGA... :-/
> > >> >
> > >> Dear Andre,
> > >>
> > >> I think this is not so different from what we added, it is rather more
> > >> comprehensive.
> > >
> > > Right.
> > >
> > >
> > >> The reasons why we implemented only the "get_mtime" are:
> > >> * many (most ?) protocols provide only 1 date (last modified).
> > >> * our users were only lacking the last modification date.
> > >
> > > Good reasons IMHO.  If everybody agrees on it, then we might
> > > indeed want to limit the change to mtime only.  However, I
> > > really would hate to come back to the topic a year later to
> > > add one attribute, and another year later for the next one,
> > > etc ;-)
> > >
> > > Lets see what the others think..
> > >
> > > Thanks, Andre.
> > >
> > >
> > >
> > > --
> > > Nothing is ever easy.
> > > --
> > >  saga-rg mailing list
> > >  saga-rg at ogf.org
> > >  http://www.ogf.org/mailman/listinfo/saga-rg
> > >
> 
> 
> 
> -- 
> Nothing is ever easy.
> --
>   saga-rg mailing list
>   saga-rg at ogf.org
>   http://www.ogf.org/mailman/listinfo/saga-rg



-- 
Thilo Kielmann                                 http://www.cs.vu.nl/~kielmann/