[sakai2-tcc] [Building Sakai] Google Summer of Code 2012

[Matthew Jones]

Bryan Holladay, Aaron and some others made a lot of fixes to issues I
personally had with unzip. There *might* still be a couple edge cases but
they should be okay, I'm pretty sure it's in 2.9 but disabled by default.
Zip is also something that was less desired but since it was already only
dealing with files on the server I think was safer to begin with. You can
choose to enable one but not the other.

There were 4 new properties:

+    /** Enable zip content handling (affects resources) */
+    public static final String RESOURCES_ZIP_ENABLE = "content.zip.enabled";
+
+    /** Set the limit of the max number of files to extract from a
zip archive */
+    public static final String RESOURCES_ZIP_EXPAND_MAX =
"content.zip.expand.maxfiles";
+
+    /** Enable zip file expansion into content (affects resources) */
+    public static final String RESOURCES_ZIP_ENABLE_EXPAND =
"content.zip.expand.enabled";
+
+    /** Enable content compression into zip file (affects resources) */
+    public static final String RESOURCES_ZIP_ENABLE_COMPRESS =
"content.zip.compress.enabled"


This ideally should be pushed off to a background processing queue/server,
similar to what exists in Jenkins, however no such functionality exists in
Sakai. That's a bummer because there's so many things that would benefit
from background processing.

Anyway, seems like something that can for sure be enabled by default to on
in 2.10 after a little more testing.

On Tue, Mar 6, 2012 at 3:10 PM, John Bush <john.bush at rsmart.com> wrote:

> We prototyped a drag and drop component that we were basically
> thinking about putting on the bottom of the resource upload page.  I
> think that project died somewhere but I liked the idea. It was just
> targetted at files, but  something like that, plus support for folders
> (not sure that's even possible), or maybe having unzip work correctly
> in resources (not sure of the current state, but I thought there were
> issues) would give us pretty good traction to hit the bulk upload
> requirements.
>
> On Tue, Mar 6, 2012 at 12:58 PM, Matthew Jones <matthew at longsight.com>
> wrote:
> > Well with flash never being supported on iOS and being depreciated from
> > Android, it probably doesn't have too long of a future anyway, so by the
> > time this was done it might be obsolete in flash. Though there were some
> > pretty neat looking uploaders. An html5 version though would be great!
> >
> > Having a *good* bulk upload in content is certainly something I've wanted
> > for awhile but the pieces just didn't seem to be there. I also wish that
> > a ProgressListener was implemented so that there was a status bar for a
> user
> > to be able to tell how long the upload was going to continue taking, and
> > maybe someday even upload in the background.
> >
> > The was some work to use the fluid uploader a few years ago at Michigan
> but
> > that was unfinished. It looks like the fluidproject website is down at
> the
> > moment, so I don't know what's up with that either.
> >
> > I agree though that content really is in need of some usability
> improvements
> > on the backend and frontend. :( And it also seems like any thick client
> is
> > going to have some issues at the moment, unless something unlikely
> happens
> > like if Dropbox open sources their client, as we could probably implement
> > that style api.
> >
> > Locally I was reminded of a app that has a free and pro version of webdav
> > for iOS and Android that is also known to work with Sakai Dav, though the
> > mobile portal is also mostly functional.
> > http://seanashton.net/webdav/
> >
> > On Tue, Mar 6, 2012 at 2:18 PM, John Bush <john.bush at rsmart.com> wrote:
> >>
> >> I think any thick client is going to have the same problems we are
> >> trying to avoid with webdav.  I think we'd be better served by having
> >> a flash or html5 type drag and drop component in CLE that would let
> >> people do bulk uploads in an easy way, but avoids having to rely on
> >> any client specific tool outside of the browser.
> >>
> >> On Tue, Mar 6, 2012 at 10:32 AM, Seth Theriault <slt at columbia.edu>
> wrote:
> >> > Matthew Jones wrote:
> >> >
> >> >> Even if we pass the litmus it still doesn't mean it would work,
> >> >> which seems like it's pretty discouraging. What would be the
> >> >> goals of this effort?
> >> >
> >> > The goal of last year's effort was to simplify the support for
> >> > WebDAV by replacing our "roll-your-own, based on Tomcat" DAV with
> >> > something updated and modern. I still think that's a valid goal,
> >> > although we appear to be exchanging one set of headaches for
> >> > another soemtimes.
> >> >
> >> > WebDAV is easier for end-users to use than sftp, even if
> >> > Cyberduck supports it. Forcing people to use Fuse or
> >> > yet-another-client doesn't make for friendliness.
> >> >
> >> > Seth
> >> >
> >> > _______________________________________________
> >> > sakai2-tcc mailing list
> >> > sakai2-tcc at collab.sakaiproject.org
> >> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> >>
> >>
> >>
> >> --
> >> John Bush
> >> 602-490-0470
> >
> >
>
>
>
> --
> John Bush
> 602-490-0470
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20120306/ffe3d520/attachment-0001.html