Angus Robertson - Magenta Systems Ltd 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. > > 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 don't know yet how to get the MIME type list from non-windows OS, however I'm confident that will work somehow :) > >>> 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? I'm quite sure. A singleton or global object would just introduce new multi-threading issues. Access to such a global has to be synchronized somehow in multi-threaded environments. Also, does it actually happen frequently that more than one or two servers are running in the same app? Well, we should realy find a reliable way to make a server capable to listen on more than just a single interface (first attempt available in the IPv6 branch) in order to eliminate the need for one instance per interface. > >> 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. In this case a hash table, as available with THashedStringList in IniFiles.pas for D7+, is the faster choice, provided the list is not changed _very frequently once it has been built. -- 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
