james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <nor...@apache.org>
Subject Re: MessageBuilder refactoring; was Re: dom / message refactoring
Date Wed, 26 Jan 2011 12:32:56 GMT
2011/1/26 Stefano Bagnara <apache@bago.org>:
> 2011/1/26 Oleg Kalnichevski <olegk@apache.org>:
>>
>>> The fact is that probably ServiceLoader was required in the previous
>>> design, using Abstract classes. That design is the only I'm aware of
>>> that would have allowed future releases to add more methods to each
>>> class without breaking compatibility with older sources. Now that you
>>> removed this possibility by switching everything to interfaces I
>>> understand that the ServiceLoader seems "horrid". Most stuff I did in
>>> the dom package has been done with this precise goal, so I can't
>>> "defend" that code if we remove the goal :-)  That said you also
>>> should understand that the ServiceLoader, like most SPI model out
>>> there, is simply an abstraction layer. You are free to directly
>>> instantiate the implementation.
>>>
>>>
>>> I didn't (and I currently don't) know a better way to create a forward
>>> compatible, yet extensible, API, but I'm far from being an expert API
>>> designer.
>>>
>>
>> Stefano
>>
>> I am sorry I do not see how the service locator pattern can help with
>> maintaining forward compatibility between releases. I always thought
>> that it's goal was primarily to decouple layers and to enable multiple
>> implementations of a service interface.
>>
>> http://en.wikipedia.org/wiki/Service_locator_pattern
>
> I wrote "the ServiceLoader, ..., is simply an abstraction layer." so
> I'm in line with wikipedia, I'm sorry if I mislead you with some other
> sentence.
>
> I try to explain with other words:
> - abstract model was there to allow forward compatibility (it is the
> only way I know that allows adding a method in the model without
> breaking everything)
> - service locator adds "indirection" (decoupling)
> You need both if you want to "publish" a single package and you don't
> want this package to have direct dependencies on the implementation.
> The 2 patterns are extensively used in the standard java class library
> and in many  common libraries (I can't take the merit for mixing them
> ;-) ).
>
> I'm not sure I understand what part of the ServiceLocator is "horrid"
> in your opinion (I don't want to force you explaining anything or to
> waste your time, but I'm always interested learning from other
> developers).
>
>>> > How do you want me to proceed now?
>>>
>>> I'm happy to see you pushing. *Go* *ahead* :-)  I just explained why I
>>> did things in a given way and how I evaluate changes. This was not a
>>> comment to stop you, but just something to let you be more informed.
>>> As long as 0.7 will support the Monitor object, the fixed headless
>>> parsing and the fixed field folding I will be happy (I currently have
>>> 0.7-SNAPSHOT as dependency for this and not for the DOM abstraction).
>>>
>>> Stefano
>>
>> I do not want to 'push' if there is no consensus that I am pushing in
>> the right direction.
>
> You should ;-)
> - You have the time to prepare a next release
> - You are a project committer
> - No one is vetoing your changes
>
> The fact that I prefer the "previous" design and I don't see critical
> "inconsistencies" in that design is just a comment (an IMHO). I accept
> to loose that stuff as in turn you'll give me back a release soon. So
> I think for both me and the community having a release with the many
> bugfix/features introduced in trunk is a big win. (hope this makes
> sense)
>
> Stefano
>

+1 Let's keep pushing for a new mime4j release :)

Bye,
Norman

Mime
View raw message