On Nov 4, 2007 10:57 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > MimeMessages are expensive to create. > > I see you wrote this twice in 2 messages: have you measured it? I never > ran a real benchmark but I know MimeMessage sources and the way we > subclassed/wrapped it and I don't see what is expensive there. > > I just want to go deeper in this because you used it as the "cause" for > "action needed" in 2 recent proposals. While I agree that javamail is > far from being a good server side api I don't think that MimeMessages > are expensive: I can see problems in the way they expose their content, > but not in their "cost" (either in term of memory or cpu).
TorqueMimeMessage is created by loading all the header rows from the database plus the byte content from the data and then using a MimeMessage to parse the bytes. this is a slow operation and consumes a lot of memory especially for big messages. the MimeMessage API is unsuitable for independent implementations. if it were a lighter interface then it might have been possible to expose only those quantities of data which were requested. the design of the API means that this isn't realistic. > The main limitations in javamail are in the store/transport > implementations: they are indeed client specific. > > Maybe it is strategic to not bind our API to javamail (I'm not sure, but > this may have advantages, so why not) but indeed if we keep a > similar/equal structure/naming for basic interfaces it would help both > porting and learning. > > Why not to try to extract the Headers interface from the javamail > InternetHeaders class? > InternetHeaders already exposes this methods: > public Enumeration getAllHeaders() > public Enumeration getAllHeaderLines() > public Enumeration getMatchingHeaders(String[] names) > public Enumeration getMatchingHeaderLines(String[] names) > public Enumeration getNonMatchingHeaders(String[] names) > public Enumeration getNonMatchingHeaderLines(String[] names) > > I agree that List<String> is easier to use than Enumerations but I > prefer to keep compatibility and similarity when the "pros" are not so big. the cost of similarity is a bloated API: MimeMessage does far too much, too badly. a major advantage of creating our own API is that it can be much simpler and so easier to implement and to use. > JAMES Server's MailHeaders could then "extends InternetHeaders > implements Headers". when using interfaces, conciseness is a virtue. i fail to see the advantage in extending an API which aleady far too bloated. the functionality in these extra methods can be easily provided by using predicates on a list of Header objects. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
