This seems like the best solution available. I would suggest however, that you consider making the default package include the more correct and complete functionality provided by the ICU. Seems more aligned with an "it just works' sort of simplicity.
As reference implementation, shouldn't the correctness of its behavior be the primary factor? Also, looking at a scenario of an "uninformed but interested party" looking to come up to speed on the ATOM spec; I don't see any benefit in offering a default configuration that fails in such a significant case simply because it is a faster or smaller implementation, or even both. Making the default configuration fail because java 1.5 fails to handle some fundamental data object correctly seems to be on the face of it just a fundamentally bad default starting point. I don't imagine that any ordinarily interested party would be necessarily be informed enough to have to digest a representative IRI-URI example and make a decision up front about which options or package configuration to download. Why complicate the approach that the novice must take to an already rather detail-rich tool? just my two cents. also, kudos and thanks for all your hard work to date. Charles On 9/13/06, Garrett Rooney <[EMAIL PROTECTED]> wrote:
On 9/13/06, James M Snell <[EMAIL PROTECTED]> wrote: > So, anyway, long story short: if we want proper support for IRIs (which > we need) then we're going to have to introduce a dependency on ICU. I'm > not happy about it, but I don't see any other way around it. > > Thoughts? James and I were just chatting about this, and the idea of making ICU an optional dependency came up. We can treat it just like the digsig stuff, if it's there you get some extra capabilities, if not then you're stuck with what we've got now, which works other than the IRI stuff. Would anyone have a problem with that? -garrett
