+1 for the interface. Maybe "writeTo" is better than "write" (the first thought when I read write(StringBuffer) is that the method write the content of StringBuffer somewhere and not viceversa).
I'm not sure I understand the size in octect. You write a StringBuffer, so it is an unicode string, how can you calculate the real octects if you don't know the charset/encoding that will be used when the buffer will be written out? Do we need to know the charset and the transfer encoding from the header of this content to be able to correctly evaluate the content or the content has already been correctly "decoded" ? Stefano Robert Burrell Donkin ha scritto: > i've been reworking https://issues.apache.org/jira/browse/JAMES-808 to > factor out an interface for content which exposes the size and allows > the content to be written. there are quite a number of different bits > of content which would benefit from the size+write approach and so > IMHO an extra interface will help to keep the API consider and > readable > > hope to commit a version today. i'd be grateful if people would take a > look at the commit diffs and either patch any design improvements they > can see or reply to list > > - robert > > /** > * IMAP needs to know the size of the content before it starts to > write it out. > * This interface allows direct writing whilst exposing total size. > */ > public interface Content { > /** > * Writes content into the given buffer. > * @param buffer <code>StringBuffer</code>, not null > * @throws MessagingException > */ > public void write(StringBuffer buffer) throws MessagingException; > > /** > * Size (in octets) of the content. > * @return number of octets to be written > * @throws MessagingException > */ > public long size() throws MessagingException; > } --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
