07-22-2020, 02:43 PM
There are really two aspects to this. 1) The speed of the check-in itself and 2) the perception to the user
The amount of time a check-in task should not really matter to the user if they don't perceive it. From any UI, this can be greatly mitigated by making sure that all check-ins are asyncronous (javascript) or in a separate thread (python). Now in the check-in widget, it seems that the uploads are asynchronous, but server.simple_checkin is not. For API calls, we have added methods preceeded by a "p_" which uses promises. There is no p_simple_checkin and there should. In this way, check-in could proceed and the use could continue working as soon a "publish" button is pressed while everything happens in the background. So the first thing to do is to add a p_simple_checkin function and to update the check-in widget to use those. In python, you should always check-in using a separate thread and provide the user progress.
As you noticed in your comment in GitHub, the largest 3 factors in the speed of the check-in are:
1) upload time
2) generation of thumbnails
3) md5 generation
There is nothing we can do about #1 from a TACTIC point of view. In TACTIC, the table generates thumbnails dynamically as needed. The reason for this was because we encountered many situations where a large number of files were ingested and thumbnail generation took an enormous amount of time. So we delayed generation of these until a user actually needs to see the thumbnail.
The MD5 generation was previously used for interfaces to be able to "quickly" determine if a file that was about to be checked in was actually different that the last version. There is a issue in Github to make this optional.
The amount of time a check-in task should not really matter to the user if they don't perceive it. From any UI, this can be greatly mitigated by making sure that all check-ins are asyncronous (javascript) or in a separate thread (python). Now in the check-in widget, it seems that the uploads are asynchronous, but server.simple_checkin is not. For API calls, we have added methods preceeded by a "p_" which uses promises. There is no p_simple_checkin and there should. In this way, check-in could proceed and the use could continue working as soon a "publish" button is pressed while everything happens in the background. So the first thing to do is to add a p_simple_checkin function and to update the check-in widget to use those. In python, you should always check-in using a separate thread and provide the user progress.
As you noticed in your comment in GitHub, the largest 3 factors in the speed of the check-in are:
1) upload time
2) generation of thumbnails
3) md5 generation
There is nothing we can do about #1 from a TACTIC point of view. In TACTIC, the table generates thumbnails dynamically as needed. The reason for this was because we encountered many situations where a large number of files were ingested and thumbnail generation took an enormous amount of time. So we delayed generation of these until a user actually needs to see the thumbnail.
The MD5 generation was previously used for interfaces to be able to "quickly" determine if a file that was about to be checked in was actually different that the last version. There is a issue in Github to make this optional.