devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <>
Subject Re: 2.0 is now alpha
Date Mon, 03 Aug 2015 16:44:24 GMT
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory
Board Member, Java Track Chair, DWX '15

Twitter @wernerkeil | @UnitAPI | @JSR354 | @JSR377 | @AgoravaProj | #DeviceMap
| #DevOps | #EclipseUOMo
Skype werner.keil | Google+

[image: --]

Werner Keil
[image: https://]

On Mon, Aug 3, 2015 at 6:13 PM, Reza Naghibi <> wrote:

> I converted the 1.0 xml device data to 2.0 json. So given we now have a
> reference client, reference domains, our device domain in 2.0, and
> everything came together as designed, I think thats enough to say we have
> an alpha release (pre beta). Beta and final release will be in the August
> and September timeframe respectively.
> *Reference client*:
> This is pretty much done. I have a few small todos. Much simpler than the
> 1.0 client and performance is still top notch, if not better. Given that
> all parsing and matching configuration is driven by the domain, 2.0 will be
> a big step forward in simplicity, configuration, and performance.
> *Reference domains*:
> There are 6 reference domains which hit on many aspects of the 2.0
> specification. This is also pretty much done.
> *Device domain* (aka device data):
> I went ahead and did a straight conversion from XML to JSON. All 1309 unit
> tests from 1.0 pass on 2.0. However, the data still contains browsers and
> other rules which need to be moved into the OS and browser domains. Also,
> the attribute spec needs to be implemented. So there will be several
> iterations of refinement and enhancements here.
> *Browser domain*:
> This is a todo. Shooting to have this done by August/September. Will be
> part of the 2.0 release.
> *OS domain*:
> This is a todo. Once again, completed by August/September. Will be part of
> the 2.0 release.
> *Java client*:
> This can be ported from the reference client. No ETA. Volkan and other
> volunteers can take lead on this.
Ideally whoever does it, try to keep "client" and "console" separate this
time. If it's something to leave as is in 1.0, so be it, but not only the
fact that .NET got a clean separation means it's worth doing the same for

> *Javascript client*:
> I will likely spearhead this if there are no volunteers. Shooting for a
> September timeframe.
What should it target, Node.js, Angular, or both? And which version of
Angular.js, as you probably heard (I saw in Rome from fellow speakers by
Google, MS and others) they got a 2.0 branch, too said to be largely
incompatible with the 1.0 code;-)

> *C client*:
> I will own this as well, however no ETA.

I personally have a whole variety of projects I contribute to, some in a
lead role (with even more duties) others in EG/team, so you don't have to
ask not to contribute to certain areas, I am relieved and got more time for
other stuff ;-D
Nevertheless, if there are interested parties for Groovy support in
Budapest, I'd be happy to help them with an initial contribution (since
they can't just commit even if they were already committers to Groovy
itself, etc.)

Aside from that proper standards are required for acceptance and inclusion
by e.g. the Portlet standard (or any other JSR that would consider it, or
say OMA/DM implemented some while ago at Eclipse) so either through the W3C
DDR implementation or if more appropriate directly I plan to help the JSR
362 EG with device support in Pluto (the Portlet RI)

The Portals and Pluto roadmap does not have it as priority by this fall
(for EDR 1) so I won't show anything, also no ETA for this, but it will be
aligned with the development or Portlet 3.0 under JCP (and Apache Portals)

I understand even in the JCP or Java EE community portlets are a large
business, but still somewhat "exotic" niche, so volunteers also from the DM
side are certainly welcome, but the Portlet team at least as of 2.0 was
quite impressive, so there should be enough resources from there (maybe
some like to help DeviceMap, too;-)


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