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

[Steve Fisher]

2009/6/2 Thilo Kielmann <kielmann at cs.vu.nl>:
> 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...

In that case I agree that we should support at most the modification
time. Presumably Java does not provide the others because they are not
universally supported.

>
> 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/
> --
>  saga-rg mailing list
>  saga-rg at ogf.org
>  http://www.ogf.org/mailman/listinfo/saga-rg
>