[Building Sakai] Resource content type and version 1.5 PDFs

[Matthew Jones]

Yea, in http://jira.sakaiproject.org/browse/KNL-101.

However it involves a little bit of work to kernel and some function
definition changes, hopefully just internal with no api changes. This
*might* still make the initial 2.7 release. I'd probably just implement it
without the option of changing the order as you'd said as that would
complicate things . And until the properties system is changed to use
Apache Commons Configuration (SAK-14640) it's harder to define complex
properties like these. (Unless done in spring) Then add the type detection
from the mime-util library. [1] Though perhaps leave the option to either
turn on or off this library until it's proven to be better, though I'm
pretty confident it will be.

[1] http://sourceforge.net/projects/mime-util/

-Matthew

On Mon, May 3, 2010 at 1:03 PM, Joshua Swink <jswink at ucmerced.edu> wrote:

> Is there a ticket in Jira for this? So that Sakai won't end up
> assigning the resource the "unknown" type?
>
> Josh
>
> On Mon, Apr 26, 2010 at 11:39 AM, Joshua Swink <jswink at ucmerced.edu>
> wrote:
> > I think this would be a good change for Sakai. I doubt it would be
> > worthwhile to make the order configurable.
> >
> > Josh
> >
> > On Mon, Apr 26, 2010 at 11:33 AM, Matthew Jones <jonespm at umich.edu>
> wrote:
> >> This would make more sense. Since Sakai trusts the browser mime first,
> if
> >> this is incorrect then the type will be incorrect. There is this 3 year
> old
> >> bug in firefox (ubuntu) which looks like it's still unfixed where pdf's
> are
> >> sent with seemingly random mime types. Some reports say
> "application/binary"
> >> some say "text/html" others say "application/x-download". Doesn't seem
> to be
> >> any specific fix other than to use a different browser.
> >> https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/84880
> >> Part of the Sakai fix I was going to work on was to put content type
> >> detection first, which "should" be the most reliable, then trust the
> browser
> >> (which as we see is isn't very accurate), then default to extension.
> However
> >> I was wondering if it would be worth it to spend extra time to try to
> make
> >> this ordering user definable.
> >> -Matthew
> >>
> >> On Mon, Apr 26, 2010 at 2:02 PM, Joshua Swink <jswink at ucmerced.edu>
> wrote:
> >>>
> >>> After more testing, I've ruled out the PDF version as the problem.
> >>> It's affecting some of our Firefox users. It is proving difficult to
> >>> pinpoint the difference in the user environments that is triggering
> >>> the problem - we have ruled out operating system and extensions.
> >>>
> >>> I turned on DEBUG.org.sakaiproject.content logging but there was no
> >>> difference between a successfully identified upload and a failed one.
> >>>
> >>> Josh
> >>>
> >>> On Thu, Apr 22, 2010 at 10:39 AM, Matthew Jones <jonespm at umich.edu>
> wrote:
> >>> > As mentioned on KNL-101 the current mime detection scheme in sakai
> is:
> >>> > Browser (if supplied), File Extension (if exists), Unknown (last
> >>> > resort),
> >>> > So for some reason the browser must be not be providing a mime type
> for
> >>> > Sakai. Then it's still unable to recognize it based on the extension
> >>> > either
> >>> > because this extension file is missing or because of some other bug?
> >>> > The default lookup file for content type extensions for 2.6 is in
> >>> >
> >>> >
> config/localization/bundles/src/bundle/org/sakaiproject/localization/bundle/content_type/content_type_extensions.properties)
> >>> > I had proposed in this SAK a few methods of fixing this process;.
> >>> > Allowing
> >>> > the detection order to be changed (trusting extension over browser?)
> and
> >>> > also possibly detecting the mime type based on a library that does
> >>> > detection
> >>> > from the actual file contents. However I never got any feedback on
> the
> >>> > list
> >>> > or SAK, and it seems like a pretty big change to make without any
> >>> > discussion, so it's kind of just hung out there. It also might have
> >>> > needed
> >>> > an internal api change as mentioned as fixTypeAndId doesn't get
> passed
> >>> > the
> >>> > file contents to examine.
> >>> > -Matthew
> >>> > On Thu, Apr 22, 2010 at 1:20 PM, Joshua Swink <jswink at ucmerced.edu>
> >>> > wrote:
> >>> >>
> >>> >> Recently we've had some version 1.5 PDFs uploaded to resources, and
> >>> >> they're not recognized by Sakai. They are "unknown". Their filenames
> >>> >> end in ".pdf".
> >>> >>
> >>> >> Two questions. First, can we update our server's type recognition to
> >>> >> identify these files correctly? Second, shouldn't it be picking up
> on
> >>> >> the ".pdf" extension, even if the internal content of the file may
> not
> >>> >> be recognized?
> >>> >>
> >>> >> Josh
> >>> >> _______________________________________________
> >>> >> 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"
> >>> >
> >>> >
> >>> _______________________________________________
> >>> 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"
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100503/881ec02e/attachment.html