james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: MessageBuilder refactoring; was Re: dom / message refactoring
Date Tue, 25 Jan 2011 23:50:08 GMT
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

Mime
View raw message