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] Pruning [WAS Re: [mime4j] Review Packaging]
Date Sat, 12 Jul 2008 19:01:54 GMT
On Sat, Jul 12, 2008 at 6:50 PM, Stefano Bagnara <apache@bago.org> wrote:
> Stefano Bagnara ha scritto:
>> Robert Burrell Donkin ha scritto:
>>> On Thu, Jul 10, 2008 at 5:54 PM, Stefano Bagnara <apache@bago.org> wrote:
>>> <sniP>
>>>> I noticed we have some unused class:
>>>> - util.StringArrayMap
>>>> - util.PartialInputStream
>>>> - util.PositionInputStream
>>>> - EOLConvertingInputStream
>>>> - CloseShieldInputStream
>>>> what should we do? (delete? deprecate?)
>>> i'd like to keep EOLConvertingInputStream around but i think the rest
>>> can be deleted
>> ok!
>>> i've been wondering whefher the interfaces i factored from
>>> MaximalBodyDescriptor are worthwhile:
>>> * RFC1864ContentMD5Descriptor.java
>>> * RFC2045MimeDescriptor.java
>>> * RFC2183ContentDispositionDescriptor.java
>>> * RFC2557ContentLocationDescriptor.java
>>> * RFC3066ContentLanguageDescriptor.java
>>> they serve to indicate the RFCs implemented but i think now they serve
>>> no substantive purpose. perhaps they should just be deleted.
>>> opinions?
>> I'm not sure what patterns we should push to better support evolution.
>> Having the interfaces let users using (obj instanceof RFCxxxxDescriptor)
>> ((RFCxxxxDescriptor) obj).rfcSpecificMethod and I would prefer this instead
>> of promoting the use of "MaximalBodyDescriptor".
>> E.g: I would like to be able to "configure" mime4j to support RFC2045 and
>> RFC3066 while I may not care of the others. Is this something that could
>> happen in a future mime4j release? In this case let's keep the interfaces,
>> otherwise we just need comments on the methods to tell what RFC they are
>> about.
> I had a fast look at the code and I see the MaximalBodyDescriptor is only
> instantiated in AbstractEntity.newBodyDescriptor.
> What about moving the implementation of each RFC to its own module and have
> AbstractEntity to create a Proxy class implementing all of the configured
> interfaces?

i'm reluctant to introduce more complexity

> At the moment we could even simply support all of them with an hardcoded
> proxy implementing every interface and delegating to each specific
> implementation and in future this could become configurable via a plugin
> mechanism (where an user could introduce his own field parsers, too).
> Is this something feasible/worthwhile?

probably feasible but i'm not sure whether it's worthwhile

> Or is there any showstopper I'm not
> evaluating?

the pluggability is fiddly and i'm not convinced that the subclassing
API is right

> If we retain RFC interfaces this could be done in a 0.5 release with no big
> impact from the API point of view.

true but i wonder whether this is really a symptom of the API not
quite working right here.

perhaps it would be more natural to be able to able to register field
processors. the field parsing code for each RFC could then be made
concrete and moved into the fields package

- robert

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

View raw message