abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles Adkins" <formofm...@gmail.com>
Subject Re: IRI Support and ICU
Date Thu, 14 Sep 2006 04:01:04 GMT
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 <rooneg@electricjellyfish.net> wrote:
>
> On 9/13/06, James M Snell <jasnell@gmail.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message