james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [mime4J] MessageSearcher...? [WAS Re: [Mime4J] getReader]
Date Mon, 10 Mar 2008 22:56:19 GMT
On Mon, Mar 10, 2008 at 10:21 PM, Noel J. Bergman <noel@devtech.com> wrote:
> Robert Burrell Donkin wrote:
>
>  >  I think that I'd rather we follow the example of other
>  >  getInputStream/getReader exemplars, and throw
>  >  java.io.UnsupportedEncodingException if it is called on a type for which
>  a
>  >  Reader is not appropriate.
>
>  > in the end, i decided that consistency was more important and elected
>  > to throw the appropriate exception.
>
>  Consistency with what?

the rest of the pull parser

>  > i don't really like having to catch runtime exceptions
>
>  Perhaps that's why the Servlet and Portlet APIs declare
>  UnsupportedEncodingException and IOException instead of
>  UnsupportedCharsetException or IllegalCharsetNameException?  I'd have to
>  check the code to see if they actually catch the latter, and return the
>  former, or if they just allow them to leak out undeclared.

IIRC UnsupportedCharsetException and or IllegalCharsetNameException
were introduced with nio

i've used both approaches to exceptions (bio and nio) quite a bit now
and i think that i prefer nio. when i specify a charset which i know
is gauranteed to be present then it's a PITA to have to handle that
exception. occasionally, i may need to use a variable charset and then
i just have to catch the runtime.

>  > > If I asked you to search
>  > > for SOMETEXT, what do I get back?  I might want a collection of [part,
>  > > first_offset]-tuples.  Less than that, and you would be discarding
>  > > information that you should already have, more than that and I would be
>  > > forcing you to do extra work that a given use case might not require.
>  On
>  > > the other hand, perhaps I just want to know about the first part in
>  which
>  > > you find it, not all parts containing it.  And can I ask that you search
>  > > only headers or parts of only certain content-type(s)?
>  > >
>  > > Point being that, yes, I'd like to have a search functionality, but I'd
>  like
>  > > some discussion over the interface and supported use cases.  And if we
>  don't
>  > > build this into an existing class, it could be a shared utility, rather
>  than
>  > > leaving it as just an example for people to clone.
>
>  > (as jukka posted) given getReader search is just a trivial pull parser
>  > application. definitely not worth a major design exercise. probably
>  > best as a worked example somewhere in the documentation.
>
>  I suspect that it will have a lot more utility than that.  Mailets will want
>  to search for text within the message structure.

but there's a balance between utility and simplicity. text searching
is now a simple application of the library. better just to give a
worked example in the documentation and then think about whether
including a simplified email-only interface as a mailet utility would
be worthwhile.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message