View Issue Details
|Fixed in Version||2.5 (リリース)|
|Summary||0000456: Separate the time cache from the update file|
|Description||I just don't quite understand why the two were put together, eh|
Users shouldn't use information about "when changes were made" in an update, and ghost authors, even if they collaborate on development, they have different change times on different computers
It seems to me that putting the two things together just creates more hassle and wasted bandwidth
So could the two be stored separately, like naming the time cache file as "updates.cache"
If you're worried about read speed, I think because the update files now have a defined file order, so you could use a design where the first line of updates.cache corresponds to the first file in updates.txt, which would even prevent you from having to write the file path in updates.cache again
Oh and please let me know if you have reasons for putting them together
|Tags||No tags attached.|
- SSP will store last succeeded update time internally and use it as "last updated time". If it was not already stored, fallback to old method.
- if you want to get update time, execute \![get,property,OnGetPropUpdateTimeEvent,currentghost.update_time]
Haha I think I didn't make myself clear, I meant that there is information in updates.txt or updates2.dau about the last updated time of each file that is not used by the user, and this is not necessary as far as I know
So I thought it might be possible to split that information from updates.txt or updates2.dau into other files
I think your suggestion is unneeded optimization, because datetime information is only 24bytes, and If there is 1000 files, the difference would only be 24KB. A difference of 24KB is within the margin of error in today's network environment.
Current specification is easy to read and write programmatically, so splitting files is not a good idea.
Only we need to improve is just ignoring datetime information during update process. I'll implement it in next version.
||2.5.82 : skipping datetime information during update process|
Thank you for the clarification! I understand.
Please close this issue
And, could you consider a slightly earlier implementation of these two issues if possible?
I have some functional ideas related to these two issues, so if you can implement these I can put that into practice.
|2022-03-12 02:54||guest||New Issue|
|2022-03-13 07:27||ponapalt||Assigned To||=> ponapalt|
|2022-03-13 07:27||ponapalt||Status||new => closed|
|2022-03-13 07:27||ponapalt||Resolution||open => fixed|
|2022-03-13 07:27||ponapalt||Fixed in Version||=> 2.5 (リリース)|
|2022-03-13 07:27||ponapalt||Note Added: 0001172|
|2022-03-13 10:30||guest||Status||closed => feedback|
|2022-03-13 10:30||guest||Resolution||fixed => reopened|
|2022-03-13 10:30||guest||Note Added: 0001173|
|2022-03-13 11:57||ponapalt||Note Added: 0001175|
|2022-03-13 11:59||ponapalt||Note Edited: 0001175|
|2022-03-13 12:00||ponapalt||Note Edited: 0001175|
|2022-03-13 12:36||ponapalt||Note Added: 0001177|
|2022-03-13 14:37||guest||Note Added: 0001178|
|2022-03-13 14:37||guest||Status||feedback => assigned|
|2022-03-13 14:55||ponapalt||Status||assigned => closed|