Re: RFC: On date and time
- From: Guillaume Emont <guijemont igalia com>
- To: grilo-list gnome org
- Subject: Re: RFC: On date and time
- Date: Thu, 02 Jun 2011 17:32:00 +0200
On 02/06/2011 16:02, Iago Toral wrote:
>
> Hi,
> On Thu, 02 Jun 2011 14:43:39 +0200, Guillaume Emont
> <guijemont igalia com> wrote:
> (...)
>> The solution I propose to solve these issues, and will start
>> implementing right now unless some people come up with better proposals,
>> is the following:
>>
>> - Store the _DATE and _CREATION_DATE keys as GDateTime. Since GDateTime
>> is generally not available/not working in language bindings, some
>> wrappers will be provided to be able to set them with strings (like it
>> is done currently, except that format checking will be done immediately)
>> - Add a GRL_METADATA_KEY_RELEASE_YEAR key that would contain an
>> integer. Some other "imprecise" date keys might be needed (please
>> suggest), but this is the only one I could think of for now. That would
>> cover things like the release year of a music album/track or the release
>> year of a film.
>
> Sounds reasonable.
>
> One question on how this should work, since _DATE and _RELEASE_YEAR are
> very related.
> Are plugin developers going to do:
>
> grl_media_set_creation_date (date)
> grl_media_set_release_year (YEAR(date))
>
> or are we going to provide something like this instead?:
>
> plugin developer only does:
> grl_media_set_creation_date (date);
>
> and then grl_media_get_release_year just gets the year from the release
> date.
Good question. I initially thought of them as separated. The pros and
cons I can see about joining them are the following:
Pros:
- release year would be more systematically set, which could make it
more useful for filtering.
- less code to set the year
Cons:
- release year and creation date might not always have an overlapping
meaning. Imagine a music album recorded in December 2010, and released
(after post-production) two months later. Worst: plugins such as
filesystem might be tempted to put the file creation time in there,
which would have nothing to do with the release year.
- setting two keys when only asking to set one might be a bit suprising
to some developers, and code that looks good like the following would
become wrong:
grl_media_set_release_year (get_year_from_mp3_tag (filepath));
grl_media_set_creation_date (g_file_info_get_attribute_uint64 (info,
G_FILE_ATTRIBUTE_TIME_CREATED));
I have a feeling that the cons outweigh the pros here, but I might be
forgetting something.
Guij
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]