Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files

2004-10-14 Thread Leonardo Rochael Almeida 
Em Ter, 2004-10-12 às 00:23, Kapil Thangavelu escreveu:
> i believe you were referring to
> http://freedesktop.org/Software/shared-mime-info
> 
> spec 
> http://freedesktop.org/Standards/shared-mime-info-spec
> 
> its a system wide shared mime database for use by applications (ie. both
> gnome and kde). apparently no python bindings.

Actually, the last url above lists a certain ROX-Lib:
http://rox.sourceforge.net/phpwiki/index.php/ROX-Lib

It's pure Python and suports a lot of stuff besides mime, but seems to
require gtk, which could be a problem for people wanting to maintain
slim servers free of any X Window System client dependencies. It's
certainly too heavy a dependency for Zope :-)

Cheers, Leo


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files

2004-10-11 Thread Kapil Thangavelu 

i believe you were referring to
http://freedesktop.org/Software/shared-mime-info

spec 
http://freedesktop.org/Standards/shared-mime-info-spec

its a system wide shared mime database for use by applications (ie. both
gnome and kde). apparently no python bindings.

-kapil


On Tue, 2004-10-05 at 10:42 -0400, Fred Drake wrote:
> ?
>  
> I think there's a library from the Gnome desktop project for this
> (basically providing something like the Unix "file" command), but I
> don't know if there's a Python wrapper for the library, or an
> all-Python re-implementation.
> 
> 
>   -Fred
> 


signature.asc
Description: This is a digitally signed message part
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files

2004-10-05 Thread Fred Drake 
On Tue, 05 Oct 2004 12:44:32 +0200, Tino Wildenhain <[EMAIL PROTECTED]> wrote:
> Well, the problem might be the asymptation part of the filename
> should be considered an indicator of its contents.

That is a nuissance.  It's unfortunate we still don't have any sort of
common type system for bytestreams that's supported in filesystems.

But disk files aren't the only source of bytestreams, so that doesn't
necessarily help us in the end.

> Arent there any libs for python to examine the contents (usually
> the first few bytes) for the type of the file?
 
I'm not aware of any for the general case.  There are a few things
like the imghdr module, but those are not for arbitrary files, and
likely aren't sufficiently capable.

I think there's a library from the Gnome desktop project for this
(basically providing something like the Unix "file" command), but I
don't know if there's a Python wrapper for the library, or an
all-Python re-implementation.


  -Fred

-- 
Fred L. Drake, Jr.
Zope Corporation
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files

2004-10-05 Thread Tino Wildenhain 
Hi,

On Tue, 2004-10-05 at 12:11, Dominic Hiles wrote:
> Dear Tres,
> 
> --On 04 October 2004 13:43 -0400 Tres Seaver <[EMAIL PROTECTED]> wrote:
> 
> > Dominic Hiles wrote:
> >
> >> Sorry, I missed these susbequent follow-ups before posting a reply a few
> >> minutes ago!  If we're going down this route, can we at least change
> >> things so that the "guessing" is done using
> >> ZServer.medusa.mime_type_table, rather than the default python mimetypes
> >> table?
> >
> > I would guess that the medusa version is more neglected than the Python
> > one;  is your experience otherwise?
> >
> 
> I now realise where my confusion came from.  Python 2.1.3 had only 85 file 
> extensions listed in mimetypes.types_map.keys() whereas 
> ZServer.medus.mime_types_table showed 106 with Zope 2.6.4.  However, Python 
> 2.3.3 is now up to 117, so I guess it makes the better choice. Apologies 
> for the noisethat said, I'm still unhappy that a browser can dictate 
> the mimetype chosen for an uploaded file, but I'm happy enough to fix that 
> at the application level.

Well, the problem might be the asymptation part of the filename
should be considered an indicator of its contents.

Arent there any libs for python to examine the contents (usually
the first few bytes) for the type of the file? 

Regards
Tino

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files

2004-10-05 Thread Dominic Hiles 
Dear Tres,
--On 04 October 2004 13:43 -0400 Tres Seaver <[EMAIL PROTECTED]> wrote:
Dominic Hiles wrote:
Sorry, I missed these susbequent follow-ups before posting a reply a few
minutes ago!  If we're going down this route, can we at least change
things so that the "guessing" is done using
ZServer.medusa.mime_type_table, rather than the default python mimetypes
table?
I would guess that the medusa version is more neglected than the Python
one;  is your experience otherwise?
I now realise where my confusion came from.  Python 2.1.3 had only 85 file 
extensions listed in mimetypes.types_map.keys() whereas 
ZServer.medus.mime_types_table showed 106 with Zope 2.6.4.  However, Python 
2.3.3 is now up to 117, so I guess it makes the better choice. Apologies 
for the noisethat said, I'm still unhappy that a browser can dictate 
the mimetype chosen for an uploaded file, but I'm happy enough to fix that 
at the application level.

Cheers,
Dominic
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files

2004-10-04 Thread Tres Seaver 
Dominic Hiles wrote:
Sorry, I missed these susbequent follow-ups before posting a reply a few 
minutes ago!  If we're going down this route, can we at least change 
things so that the "guessing" is done using 
ZServer.medusa.mime_type_table, rather than the default python mimetypes 
table?
I would guess that the medusa version is more neglected than the Python 
one;  is your experience otherwise?

Tres.
--
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation  "Zope Dealers"   http://www.zope.com
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files

2004-09-30 Thread Dieter Maurer 
Tres Seaver wrote at 2004-9-30 10:03 -0400:
> ...
>In summary, I would prefer the precedence to be:
>
>   1. Passed value
>
>   2. Request header
>
>   3. Guessed value

+1

-- 
Dieter
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files

2004-09-30 Thread Tres Seaver 
Jan-Wijbrand Kolman wrote:
-1 for using the "guessed" value over the one from the headers;  +1 
for using the argument over the guessed value (so that the application 
can "fix" the problem).  I agree that having different clients supply 
different types is painful, but I don't think that "fixing" it at the 
low level is reasonable (mechanism vs. policy).

Can you elaborate a bit more on the "mechanism vs. policy" remark? I'm
not sure I understand your line or reasoning and I'm curious for it :)
OK.  The OFS.Image code we are talking about is fairly low-level, and is 
used widely across applications.  It should thus be as "policy-free" as 
possible, so that applications which need different policies can still 
reuse the mechanism.  Thus, it should *never* override the values passed 
explicitly by the application (which are themselves "policy").

Overriding the header value passed by the client itself with one guessed 
by mimelib is *also* a policy, and one which the application could / 
should make;  otherwise, we end up with the alternate problem, which is 
that clients which do the Right Thing get stomped on.

"Guessing" should always be last in line, and used (at least by default) 
only in the absence of explicit information.

Tres.
--
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation  "Zope Dealers"   http://www.zope.com
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files

2004-09-30 Thread Jan-Wijbrand Kolman 
Tres Seaver wrote:
-1 for using the "guessed" value over the one from the headers;  +1 for 
using the argument over the guessed value (so that the application can 
"fix" the problem).  I agree that having different clients supply 
different types is painful, but I don't think that "fixing" it at the 
low level is reasonable (mechanism vs. policy).
Can you elaborate a bit more on the "mechanism vs. policy" remark? I'm
not sure I understand your line or reasoning and I'm curious for it :)
regards,
jw
--
Jan-Wijbrand Kolman
[EMAIL PROTECTED]
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: inconsistent mimetype assignment for uploaded files

2004-09-30 Thread Tres Seaver 
Jan-Wijbrand Kolman wrote:
Hello,
we recently realised mimetype assignment in Zope to e.g. Zope File
objects is inconsistent and can vary when different clients (browsers)
upload files with the same file extensions.
Example: when a file called "foobar.rtf" is upload to a Zope File
object from Linux Firefox, the mimetype assigned is (can be)
'application/rtf'. However, the same file uploaded to the same Zope
File object in the same Zope instance, using IE on Window2000 (with MS
Office installed) will get 'application/msword' assigned.
The mimetype assignment for uploaded files is done in OFS.Image.py
(maybe there're more places or other Products that do this - I know
that at least ExtFile does this too). line 463 of OFS.Image.py, Zope
2.7.2:
def _get_content_type(self, file, body, id, content_type=None):
headers=getattr(file, 'headers', None)
if headers and headers.has_key('content-type'):
content_type=headers['content-type']
else:
if type(body) is not type(''): body=body.data
content_type, enc=guess_content_type(
getattr(file, 'filename',id), body, content_type)
return content_type
Then I understood that the headers as sent by the client for this file
(may?) have a content-type entry that takes precedence over both the
mimetypes 'database' and the content_type passed in as an argument.
We could deal with the inconsistent assignment on the application
level (in this case Silva), but I'd rather consider changing this
behaviour on the Zope level. I could imagine changing the way a
mimetype is 'guessed' from an uploaded File to something like:
def _get_content_type(self, file, body, id, content_type=None):
"""
Order of precedence:
1) see if guess_content_type resolves to a mimetype for the
   filename
2) if not use content_type as sent in the headers if
   available
3) else use argument passed in
"""
headers = getattr(file, 'headers', {})
content_type = headers.get('content-type', content_type)
if type(body) is not type(''):
body = body.data
name = getattr(file, 'filename', id)
content_type, enc = guess_content_type(name, body, content_type)
return content_type
Does anyone have an opinion on this? Is the current behaviour
completely intentional, maybe even according to some specification
(and thus I should deal with it on the application level)? Should I
file a collector issue?
-1 for using the "guessed" value over the one from the headers;  +1 for 
using the argument over the guessed value (so that the application can 
"fix" the problem).  I agree that having different clients supply 
different types is painful, but I don't think that "fixing" it at the 
low level is reasonable (mechanism vs. policy).

In summary, I would prefer the precedence to be:
  1. Passed value
  2. Request header
  3. Guessed value
Tres.
--
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation  "Zope Dealers"   http://www.zope.com
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )