Skip Menu |

This queue is for tickets about the MIME-Types CPAN distribution.

Report information
The Basics
Id: 59367
Status: resolved
Priority: 0/
Queue: MIME-Types

People
Owner: Nobody in particular
Requestors: tlhackque [...] yahoo.com
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 1.30
Fixed in: (no value)



Subject: Maintain contexts; optimizations
I have a case where an application works on two libraries simultaneously, and where each can be configured with its own list of additional - private - types. This is a bit hard to deal with in the current implementation of MIME::Types. MIME::Types maintains only one global list; addType adds to that one global list. It would be better if addType maintained the list of additions in the object; e.g. $self->{addedTypes}{addition} = ... Then mimeTypeOf (and friends) would check the object first, then the global list. This would keep the memory saving of a global list for the pre-compiled types, but would allow additions to be per-object. Related: it's expensive to initialize MIME::Types - it spends a lot of cycles reading and re-indexing the database. And it does it again whenever an add invalidates the index. Keeping a separate index for the additions would make re-indexing cheaper, since it would only have to deal with the additions... It would also be better if the index (or indexes when the object has one for the additions) was pointed to by the object. This would allow an application to save the expense of reading and constructing the list index for each transaction by serializing and caching the object. (It can detect updates by caching $MIME::Types::VERSION with the object...) FWIW,
Subject: Re: [rt.cpan.org #59367] Maintain contexts; optimizations
Date: Wed, 14 Jul 2010 21:24:13 +0200
To: via RT <bug-MIME-Types [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* via RT (bug-MIME-Types@rt.cpan.org) [100714 17:44]: Show quoted text
> Wed Jul 14 13:44:33 2010: Request 59367 was acted upon. > Transaction: Ticket created by tlhackque > Queue: MIME-Types > Subject: Maintain contexts; optimizations
Many questions for one ticket :( Show quoted text
> I have a case where an application works on two libraries > simultaneously, and where each can be configured with its own list of > additional - private - types. This is a bit hard to deal with in the > current implementation of MIME::Types.
The core concept for the existence of Mime-types, as maintained by IANA, is that everyone uses the same strings to represent the same type. So, your suggestion to permit two lists which differ is conceptionally very against this core concept. Show quoted text
> Related: it's expensive to initialize MIME::Types - it spends a lot of > cycles reading and re-indexing the database. And it does it again > whenever an add invalidates the index. Keeping a separate index for > the additions would make re-indexing cheaper, since it would only have > to deal with the additions...
Database? A HASH is not a database. It does not have an index. Show quoted text
> It would also be better if the index (or indexes when the object has > one for the additions) was pointed to by the object. This would allow > an application to save the expense of reading and constructing the list > index for each transaction by serializing and caching the object. (It > can detect updates by caching $MIME::Types::VERSION with the object...)
I have fague plans to maintain the data differently, but the thaw of a binary blob, as you suggest, will probably not be faster than the split which I have now. In the ideal world, all mime-types are registered at IANA. More and more applications define their own private list. Are your types useful for other people? -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
no response from the requestor anymore, nothing to do left