devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Naghibi <re...@apache.org>
Subject Re: Clients
Date Tue, 14 Apr 2015 17:31:55 GMT
I think its best to focus on the current project and how to move it
forward. Using heavy hitting projects like CLDR as a guide for us is just
more hand waving.

I've pretty much washed my hands of this project and will announce my
departure soon. Don't worry, this decision was made weeks ago, I just
haven't had the time to put together my announcement, but I guess this is a
start.

What you (and others) should start focusing on now is next months board
report and what the roadmap is for this project. Then of course you need to
execute. Citing other projects wont help you here.


On Tue, Apr 14, 2015 at 8:56 AM, Werner Keil <werner.keil@gmail.com> wrote:

> Speaking of CLDR, I forgot Apache Commons Lang in its 3rd iteration:
> http://commons.apache.org/proper/commons-lang/
> It still supports java.util.Date/Calendar (also backed by CLDR) despite
> brand new java.time available.
> Maybe there's going to be apache.commons.lang4 based on Java 8.0+ some day,
> but they haven't even started any effort on that;-)
> Commons-lang SVN however is a perfect example for multiple branches:
> http://svn.apache.org/viewvc/commons/proper/lang/
>
> The 1.0 branch can be considered true "legacy" as it wasn't updated in 7
> years. The 2.0 branch saw at least some activity, maybe bugfixes till about
> a year ago.
> And trunk is the 3.0 branch.
>
> CLDR shows how a vast repository can be maintained simply via a ticket
> system (Trac) and source code (also SVN),
> http://cldr.unicode.org/development/editing-cldr-spec shows how they do it
> like that.
>
> So if you're really committed to committing to improved versions of data,
> clients or both, please go ahead, otherwise feel free to use data from
> another set of clients.
>
> On Tue, Apr 14, 2015 at 2:44 PM, Werner Keil <werner.keil@gmail.com>
> wrote:
>
> > Nobody is off track, and just look at CLDR, there are 4 competing Java
> > clients, some older some recently added (but also with a nearly 10 year
> > "legacy" see JSR 310) to Java 8.
> > Neither of them is abandoned, so any project (inside and outside
> > Apache.org) is free to implement APIs and standards that exist (such as
> W3C
> > DDR standard;-) or
> > do something else.
> >
> > Chose where you want to do this, either at Apache or in your own project,
> > Bertrand stated the options or contraints for doing that already.
> >
> >
> > On Tue, Apr 14, 2015 at 2:32 PM, Reza Naghibi <rezan@apache.org> wrote:
> >
> >> You are getting way off track again. The issue has *never* been
> supporting
> >> multiple clients in different languages. Multi language support via a
> >> standard specification is the cornerstone of what I have proposed in
> 2.0.
> >> The issue has *always* been the legacy OpenDDR Java client which seems
> to
> >> always pop up and disrupt the progress of this project.
> >>
> >> On Tue, Apr 14, 2015 at 8:23 AM, Werner Keil <werner.keil@gmail.com>
> >> wrote:
> >>
> >> > Interesting, so WebDriver has also become a W3C spec.
> >> > The GitHub project https://github.com/seleniumhq/selenium
> >> > shows how this W3C standard is supported by multiple languages.
> >> >
> >> > It seems a bit more strict on some atrributes and terms than W3C DDR,
> >> but
> >> > otherwise the two written specs are not so different after all.
> >> > The way this is handled in at least 5 major programming languages can
> be
> >> > seen as a good example on how to do this.
> >> >
> >> > Oh and an inspiration for screen-size and similar size properties can
> be
> >> > found under:
> >> >
> >> >
> >>
> https://w3c.github.io/webdriver/webdriver-spec.html#dictionary-windowsize-members
> >> >
> >> > CSS3 knows a variety of units, mainly for length, but also others like
> >> > duration (for animation) and more, so as mentioned earlier, why not
> also
> >> > follow these when we store similar measurements in a 2.x repository?
> >> >
> >> > Werner
> >> >
> >> >
> >> > On Fri, Apr 10, 2015 at 3:44 PM, Werner Keil <werner.keil@gmail.com>
> >> > wrote:
> >> >
> >> > > One project best compared to DeviceMap and the DDR would be CLDR,
> the
> >> > > Unicode Common Data Repository: http://cldr.unicode.org/
> >> > > It is one of the most widely used, but at the same time most
> >> > > underestimated projects many "sexy" and popular ones use but hide
> well
> >> > > behind the scenes.
> >> > >
> >> > > Hence, speaking about it barely ever happens (I proposed a talk
> around
> >> > > Eclipse Babel and Unicode a while ago which was turned down for
> being
> >> not
> >> > > interesting enough;-)
> >> > > Nevertheless the biggest names in the industry from Apple to Google,
> >> IBM
> >> > > or (yep also) Adobe certainly use it and some are active
> contributors.
> >> > > When met Bertrand in Zurich a while ago, Google was represented by
> >> > Unicode
> >> > > co-founder Mark Davis.
> >> > >
> >> > > The repository is also based on XML though JSON extracts exist, but
> >> they
> >> > > are merely for convenience, not the driving data source as of now.
> >> > >
> >> > > Java alone has at least 2 or 3 different clients;-D The JDK has 2(!)
> >> > > competing APIs alone, java.util.Date and Calendar as well as
> java.time
> >> > > since Java 8. Both use CLDR data converted by Sun/Oracle. While
> ICU4J,
> >> > the
> >> > > IBM lead "official" Java API for Unicode does the same in a slightly
> >> > > different way. No real battle between them. ICU4J influenced a few
> >> > patches
> >> > > and fixes of the JDK equivalents. And you can be pretty sure,
> Eclipse
> >> or
> >> > > Apache (Harmony) plus derived work like Android won't give up the
> >> > > "old-fashioned" ICU4J (that's at least how Stephen Colebourne, a
> main
> >> > > committer to "java.time" called it) and all jump the java.time
> >> bandwagon
> >> > > even if they use Java 8 already.
> >> > >
> >> > > Cheers,
> >> > > Werner
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >
> >
>

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