2011/1/18 Oleg Kalnichevski <[email protected]>: > I understand the downside of having a pure interface based API. However, > you seem to be very keen to position mime4j not only as a utility for > parsing and building mime messages but also as an abstract Document > Object Model with different / alternative implementations. I just do not > see how one can honestly call the existing code in trunk an abstract > Object Model if the only aspect that is abstract is field parsing. We > should either drop the pretense at having an abstract DOM in mime4j and > revert to the state existed before your changes or actually make an > effort to define a truly abstract model even if that means more effort. > > I am very fine with just reverting to the old state, by the way. > > So, what shall I do?
Go ahead with your plan. I agree that DOM is incomplete now. I don't think that we'll see alternative implementations, but having a good DOM api is also a way to stabilize an interface and put a clear limit in what can be changed and what cannot be changed. I would like before 1.0 to tell people feel free to refer .dom. classes, don't touch .field./.message./.storage./ . Having no direct dependencies from dom to the implementation is a way to be sure this happen. >> [...] BTW I'm just loud thinking, just go ahead with >> your plan :-) > > I am going to get there shortly. I just prefer to make potentially > contentious changes in small, incremental steps, so that they are easier > to review and agree / disagree upon. I understand. I'm impatient to see your changes :-) Happy hacking Stefano
