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

[Matthew Jones]

I'm also on the side of commenting it rather than providing a
property. It seems like this could be done by 2.6.1 but not by the
first 2.6.0. The stack trace in dropbox, the permissions issue and the
stack dumps that should throw error messages to logs with no response
to the user were 3 functional ones. Beyond that since it isn't
performance tested and it has large delays in certain conditions we'd
probably still need a property that could limit its availability.

Something like
#Turn off the option
resources.option.zip=false
#Everyone can use the option
resources.option.zip=true
#Only people with maintain role can use the option
resources.option.zip=maintain

Since we are pushing for a release soon, this idea wouldn't be
resolved in the very near term if I were working on it.

I'm +1 for commenting it now, and I'm also +1 for improving it and
adding it as an property eventually (as I also patch it in
occasionally, but only on a development server)

Since it looks like you've decided to property it, I'd still make this
clear in sakai.properties (if you decide to even put it in there and
make it public) that this feature does have known bugs and we
recommend that it be left disabled at present time.

-Matthew

On Thu, Apr 16, 2009 at 1:59 PM, Adam Marshall
<adam.marshall at oucs.ox.ac.uk> wrote:
> We use SAK-800 in production and whereas the zipping up is a bit flaky, the
> unzipping seems to work fine.
>
> As we have to apply the SAK-800 patch for each build, we'd like to see it in
> the code base protected by a property that by default disables the
> functionality.
>
> Perhaps if it is available in the download, some kind soul may fix the
> outstanding problems (and add an option to save the ZIP file on one's local
> machine!)
>
> Adam
>
> | -----Original Message-----
> | From: sakai-dev-bounces at collab.sakaiproject.org [mailto:sakai-dev-
> | bounces at collab.sakaiproject.org] On Behalf Of Anthony Whyte
> | Sent: 16 April 2009 18:16
> | To: Sakai-Dev Developers
> | Cc: Sakai QA
> | Subject: [Building Sakai] KNL-155/SAK-16036/SAK-800: Resources archive
> | filehandling issues
> |
> | 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"
>