[WG: Sakai QA] [Building Sakai] KNL-155/SAK-16036/SAK-800: Resources archive file handling issues

[David Haines]

+1 for commenting it out.  That seems like the least possible change.

- Dave



David Haines
CTools Developer
Digital Media Commons
University of Michigan
dlhaines at umich.edu




On Apr 16, 2009, at 1:16 PM, 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.
>
> Cheers,
>
> Anth
>
>
> Further reading:
>
> http://bugs.sakaiproject.org/jira/browse/KNL-155
> http://bugs.sakaiproject.org/jira/browse/SAK-16036
> http://bugs.sakaiproject.org/jira/browse/SAK-15995
> http://bugs.sakaiproject.org/jira/browse/SAK-800
>
> 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  
> FileUploadExpandAction());
>
> 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 =  
> false."_______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"