You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2008/07/12 09:22:16 UTC
[mime4j] Pruning [WAS Re: [mime4j] Review Packaging]
On Thu, Jul 10, 2008 at 5:54 PM, Stefano Bagnara <ap...@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
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?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] Pruning [WAS Re: [mime4j] Review Packaging]
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sat, Jul 12, 2008 at 6:50 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Stefano Bagnara ha scritto:
>> [...]
>> 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, can you elaborate on this old discussion and maybe open a JIRA
issue so we don't loose track of this?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] Pruning [WAS Re: [mime4j] Review Packaging]
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, Jul 12, 2008 at 6:50 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Stefano Bagnara ha scritto:
>>
>> Robert Burrell Donkin ha scritto:
>>>
>>> On Thu, Jul 10, 2008 at 5:54 PM, Stefano Bagnara <ap...@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
Re: [mime4j] Pruning [WAS Re: [mime4j] Review Packaging]
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> Robert Burrell Donkin ha scritto:
>> On Thu, Jul 10, 2008 at 5:54 PM, Stefano Bagnara <ap...@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?
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? Or is there any showstopper I'm
not evaluating?
If we retain RFC interfaces this could be done in a 0.5 release with no
big impact from the API point of view.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] Pruning [WAS Re: [mime4j] Review Packaging]
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Thu, Jul 10, 2008 at 5:54 PM, Stefano Bagnara <ap...@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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] Pruning [WAS Re: [mime4j] Review Packaging]
Posted by Bernd Fondermann <be...@googlemail.com>.
On Sat, Jul 12, 2008 at 9:22 AM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Thu, Jul 10, 2008 at 5:54 PM, Stefano Bagnara <ap...@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
+1
>
> 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.
RFC compliance should go into documentation.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org