[WG: Sakai QA] [Building Sakai] KNL-155/SAK-16036/SAK-800: Resources archive file handling issues
jleasia at umich.edu
Thu Apr 16 10:35:04 PDT 2009
Seems like the safest at this date - least impact/risk on the code - is
comment the couple lines that put up the menu item.
Anthony Whyte wrote:
>In April 2008 code was merged into trunk /content (r 45419, 45421)
>and the API and service modifications were later repackaged in the
>kernel (K1) in order to provide the ability to create/extract from
>archive file types (e.g., .zip, .tar, .tgz). The most recent
>comments in SAK-800 combined with recent testing by Matt Jones of
>UMich (as reported in KNL-155) indicates that this feature still has
>a number of problems associated with it (Matt's comments are below).
>Given these concerns and the short time frame that now exists with
>respect to the upcoming 2.6.0 release Matt has suggested the
>following options in lieu of fixing it:
>1) remove it
>2) comment it out
>3) wrap it in a property setting (enable/disable) and add the new
>property (e.g., resources.zip.experimental = false) to /config
>default.sakai.properties. Default = disabled.
>I'd appreciate your opinion on the matter.
>KNL-155/SAK-16036. Matt Jones comments:
>"Since there were still so many issues with SAK-800, it's status was
>recently brought up by Stephen on the QA mailing listlist, Because of
>followup concerns and based on the comments for on the jira for
>SAK-800, I believe that it shouldn't be released in the final build.
>This contributed patch was merged into trunk in an unfinished state
>and made it into the 2.6 release. Ideally the issues in this patch
>should be resolved but this will unlikely happen before the release
>and it should not hold it up.
>Here were my comments on the QA list:
>- There is no feedback to the user when anything goes bad, as the
>link appears on resources that you don't have permission to (this
>could be checked for permission first in FolderCompressAction) and
>there was an NPE as indicated on the jira.
>- No solution for extracting files that already exist in resources
>- If the zip file or number of contained files is large, the
>extraction/compression might take a long time and the UI will block
>interaction rather than threading it. An alternative would be to have
>it check sizes in advance. I think I even tested a zip file
>containing 0K small files and it took almost 5 minutes to uncompress.
>- I wasn't sure if compressing large files/directories ran into
>memory errors or not, some of these edge cases should be tested.
>- I don't think I tested what happens operated on really isn't a zip
>file, just has a .zip extension There's no error messages shown by
>the tool, so
>- More errors in general need to be show to the user.
>This should be able to be easily disabled in the UI, you'd just have
>to wrap up
>the actions in FileUploadType/FolderType
> actions.put(ResourceToolAction.EXPAND_ZIP_ARCHIVE, new
>I don't know if we'd want to wrap these up with a user settable
>sakai.properties value, comment it out of the code or unmerge this
>patch. It would be nice to eventually see it working. I would
>probably vote to disable via property just to give someone interest
>on possibly working on it again. Like resources.zip.experimental =
>sakai-dev mailing list
>sakai-dev at collab.sakaiproject.org
>TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sakai-qa