Re: [twsocket] Setting additional Header fields depending on themimetype in th
RTT wrote: On 13-12-2011 19:21, Arno Garrels wrote: We don't want to open and load a text file each time a new type is found. True, that would be dog-slow. For the generality of the HTTP server applications, other than the 10 or 15 most common MIME types (that should always be in the list) and the ones that are application specific (application adds these to the list), all the rest are exotic ones, only requested once in a while, if even. Reading these from the registry, of even from an external file, is, IMO, the best way to code it. Implementation in the webserver component should IMO not load from system/registry by default but just add currently hard coded types. Property MimeTypes could return an instance or interface with methods for everthing else including load from file, registry and resource etc.. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Setting additional Header fields depending on themimetype in th
On 13-12-2011 14:43, Arno Garrels wrote: I would not link headers with MIME types (in the same list) but rather keep it clear and simple. This new class should also be usable from other components such as the SMTP client. Totally agree with that. Associating header elements to the content-type is completely application specific. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Setting additional Header fields depending on themimetype in th
Angus Robertson - Magenta Systems Ltd wrote: If filling from the registry, better if the list is filled dynamically when a not yet resolved file extension is requested. Except that scanning a single registry node or file, allocating memory for those nodes, and building indexes for them may be more efficient in one function. Full ACK, it's one shot, I won't care whether that takes a few milliseconds longer or not, more important is _lookup speed. We don't want to open and load a text file each time a new type is found. True, that would be dog-slow. I agree that memory is needed for all the MIME types, so it probably wants to be a global object shared between multiple servers, maybe with the existing code left as a default. IMO memory use of 200-400 short MIME type strings is minor, nothing we should worry about today. I was only planning on checking: [HKEY_CLASSES_ROOT\MIME\Database\Content Type Not the full classes root. OK, may be faster than my test posted previously which still has room for optimization though. I was also thinking about two indexes, one of MIME types actually used, the other the hundreds or thousands that are actually registered. Lookups from a hash table are hell-fast, until there are collisions. However with such a small number of key/value pairs lookups will mostly just take O(1), no need to split the database, if I got your intention right. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Setting additional Header fields depending on themimetype in th
We don't want to open and load a text file each time a new type is found. True, that would be dog-slow. We need to think about Linux/OSX, this will be first use of registry access in ICS, I've already done some stuff to help decoding MIME email content. I agree that memory is needed for all the MIME types, so it probably wants to be a global object shared between multiple servers, maybe with the existing code left as a default. IMO memory use of 200-400 short MIME type strings is minor, nothing we should worry about today. Are you sure? If there are say six listen sockets, do we really want to load and keep separate MIME tables for each? Lookups from a hash table are hell-fast, until there are collisions. I've only used binary search lists, mostly written before Delphi got hash lists, and was expecting more than a few hundred items so there would be several tests to find an item. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Setting additional Header fields depending on themimetype in th
On 13-12-2011 19:21, Arno Garrels wrote: We don't want to open and load a text file each time a new type is found. True, that would be dog-slow. For the generality of the HTTP server applications, other than the 10 or 15 most common MIME types (that should always be in the list) and the ones that are application specific (application adds these to the list), all the rest are exotic ones, only requested once in a while, if even. Reading these from the registry, of even from an external file, is, IMO, the best way to code it. Even so the new MIME class may have a property to specify if the extended list should be loaded dynamically, or not. This way application developers decide the best method that suits his needs. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
