Fix Version/s: None
"Create Bag on object modification" is an ironclad method for ensuring preservation of objects, but it is resource intensive.
For example, if one edits the metadata of an object, Create bag on object modification is triggered. If that object is a large object, say a 4GB WAV object, then a simple metadata edit triggers a 4GB bag export and hangs the web browser until completion.
Instead of holding the web browser hostage, maybe Create bag on object modification can be deferred. What's truly important is not to lose record of the modification action, so a freshened bag may be produced at some time. It's when the bag is produced that's an issue, due to the web browser hanging on while the bag is generated.
Using a deferred strategy, bag production could be started via drush at the best time of the day determined by the systems administrator, ex: after everyone has gone home for the day.
A deferred strategy could also solve another related issue, multiple edits on an object per day. Today, with each metadata edit, a freshened bag is created. If multiple metadata edits happen to the same object during the same day, the bag will be generated multiple times per day. If deferred, the bag could possibly be generated only once, just based upon the last record of modification.
Regardless, bag generation should be backgrounded, letting go of the web browser so the employee can continue on with their workday, instead of having to hang on and wait for a large object bag to be produced. Sure, browser tabs are helpful in this endeavor, but browsers have memory limits too.