[TYPO3-dam] media types

[ben van 't ende [netcreators]]

René Fritz wrote:
>> These lists
>> are rather long ;-)
> 
> I don't care. So DAM will become the most largest extension ever :-)
> 
>> types are categorised? We had quit a good division at that time I think. At
>> the moment some things seem to be mixed up. odt and tmpl are categorized as
>> undefined, sxw as application etc. Files like odt, doc could be categorized
>> as Text 
> 
> The list could be improved, for sure. I have currently not my focus on this 
> topic. I can inlude types when you say me what and how.
> Nevertheless I have on my todo list to provide configuration options which 
> resource should be used for mime type detection (builtin or system dependent)
> 
>> as there is the Additional meta data field. These kind of files can 
>> carry extra metadata.
> 
> I don't get this. I may misunderstand you, but that a file has meta data is 
> independent of the detection of it's mime type, isn't it?

Hey,

As I understand it some fileformats can carry metadata. The office formats can
carry added metadata which should go into the Additional metadata. So this field
should also be there for application.

> 
>> http://www.iana.org/assignments/media-types/
> 
> An excerpt of the mime type list is already used in DAM. Unfortunately is that 
> list not exactly what I think is right for DAM. For example 'pdf' is defined 
> there as
> 	application/pdf 
> and not as 
> 	text/pdf
> Technically this may be correct but from a categorization like DAM use I would 
> expect it of type 'text'. And that's how DAM has an additional internal list 
> defined. Btw. Open Dokument formats are also defined as application/* in the 
> mime type list not text.

I don't consider these text because of the fact that text can be extracted from
them by some parser. csv,txt,tmpl,html,css etc. are text to me, because there is
no special aplication needed to view them.

> Here's how media/mime type detection works (example.pdf):
> 
> - Get the file extension, This is 99.999% correct in my eyes so I trust this 
> information: 'pdf'

ofcourse

> - If we have a file extension use an internal array to get a mime type for: 
> application/pdf

I noticed that for instance odt does not get the mime type. This list is
probably not complete.

> - if the internal list does not know the type mime_content_type() is used to 
> get a mime type. Now the detection depends on the servers setup.

I don't get this. Where is that defined on the server?

> - if we still don't have a mime type or there's no file extension use 
> the 'file' command to detect these
> 
> Now we know
> file_type=pdf
> file_mime_type=application
> file_mime_subtype=pdf
> 
> An internal array is used to get the media type (text, image, ...) for a file 
> type. This overrides the mime type and makes from an pdf of 
> file_mime_type 'application' the media_type 'text'.
> If that fails the file_mime_type is used.
> 
> The function
> tx_dam::register_fileType()
> can be used to define new types. So easily the internal lists can be 
> customized by own extensions.

I would rather have this standardised in DAM than having to do this with an
extension later on. Or do you feel there are different media types in different
projects?

> The internal arrays itself are in dam/lib/tx_dam_types.php and can be modified 
> to but may change in the future.

I didn't have a look at that file yet.

gRTz

ben
-- 
netcreators :: creation and innovation
www.netcreators.com -  www.typo3.nl