2011/1/26 Stefano Bagnara <[email protected]>: > 2011/1/26 Oleg Kalnichevski <[email protected]>: >> >>> 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
