search

anansi-project / comicinfo

ComicInfo.xml's new home
https://anansi-project.github.io/docs/category/comicinfo
MIT License
136 stars 8 forks source link

New Element: Last Updated date #31

Closed Drudoo closed 1 year ago

Drudoo commented 2 years ago

Where does this comes from?

Myself.

What is the rationale for adding support for this element?

I am in the process of writing a plugin, where Comicrack will export more data into cbz files. I would like to implement that the new schema from this repo so each comicinfo.xml file will contains the new schema.

In order to keep track of when a file was updated with the new comicinfo.xml file, a field that contains the last updated date, would be very useful.

Is the element already handled by any application or tool?

Not that i know of.

gotson commented 2 years ago

In order to update the ComicInfo.xml file inside a CBZ/CBR, you need to recreate the zip/rar archive anyway, so the file will have the modified time.

What will that new field accomplish, that couldn't be done using the file last modified field from the file sysrtem?

baodrate commented 2 years ago

More accurately, not the mtime of the archive file itself (converting a .cbr -> .cbz doesn't change the contents' "Last Updated date") but the mtime of the ComicInfo.xml within the archive.

Drudoo commented 2 years ago

In order to update the ComicInfo.xml file inside a CBZ/CBR, you need to recreate the zip/rar archive anyway, so the file will have the modified time.

What will that new field accomplish, that couldn't be done using the file last modified field from the file sysrtem?

Renaming a file using eg Library Organizer in CR would update the file mod time, and that doesn’t necessarily mean the comicinfo file was modified.

majora2007 commented 2 years ago

I'm not understanding the need for this at a spec level. This sounds like you have a niece system that uses ComicInfo as it's database and you're adding maintenance stuff to the ComicInfo. While this can be done, at a spec level it doesn't make sense when the ComicInfo was updated as it's there to provide information to the consuming application.

Drudoo commented 2 years ago

That’s fair enough. If nobody else see a usecase, then of course don’t implement it. I was interested in seeing if others would find it useful. I’ll get around it for my own usecase.

majora2007 commented 2 years ago

Just to point out, you can still include it in your ComicInfo.xml files. No consumer to my knowledge validates against the spec formally. But from my point of view, it doesn't seem like a good place within the spec.

baodrate commented 2 years ago

Renaming a file using eg Library Organizer in CR would update the file mod time, and that doesn’t necessarily mean the comicinfo file was modified.

Can you not get the mtime of the ComicInfo.xml inside the archive? Does comicrack rewrite that file as well, even when it hasn't changed?

Drudoo commented 2 years ago

Just to point out, you can still include it in your ComicInfo.xml files. No consumer to my knowledge validates against the spec formally. But from my point of view, it doesn't seem like a good place within the spec.

True, but i've been following this project for some time and would like to respect the specs if i build something new.

Can you not get the mtime of the ComicInfo.xml inside the archive? Does comicrack rewrite that file as well, even when it hasn't changed?

Sure, that could be done, but that need an extra call compared to just reading the content of the xml file.

Again, this seems like a controversial suggestion, so i'll find a way around it.

gotson commented 2 years ago

Sure, that could be done, but that need an extra call compared to just reading the content of the xml file.

Just to point out, you can still include it in your ComicInfo.xml files. No consumer to my knowledge validates against the spec formally. But from my point of view, it doesn't seem like a good place within the spec.

True, but i've been following this project for some time and would like to respect the specs if i build something new.

Can you not get the mtime of the ComicInfo.xml inside the archive? Does comicrack rewrite that file as well, even when it hasn't changed?

Sure, that could be done, but that need an extra call compared to just reading the content of the xml file.

Again, this seems like a controversial suggestion, so i'll find a way around it.

on the contrary, you don't need to extract the file itself to get the mtime