devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <>
Subject Re: Call for Papers: "ApacheCON: Core" in Budapest October 1-2 2015.
Date Wed, 01 Jul 2015 15:36:47 GMT
OK, there is not much time left so I submitted the proposal with an updated

We experience a growing number of mobile and similar devices flooding the
market almost every day. Capturing the specification of each device is a
tough job. If you want to create a great UX you need dynamic content
matching hardware and browser specs of your device. That’s why Device
Description Repositories (DDR) exist. Apache DeviceMap is a collaborative
effort by Adobe, OpenDDR and others to create a comprehensive open-source
and open-data repository of device information and other relevant data for
all types of devices. The project began in January 2012 after which OpenDDR
contributed data and APis for Java and. NET. DeviceMap left Apache the
Incubator Nov 2014. After modularization, DeviceMap 2.0 shall make
classification generic, so people can introduce their own detection
domains. Support further languages like JavaScript/Node.js, etc. and a JSON
representation of device data.

If you spot anything major respond quick, otherwise fingers crossed, they
like it again this year.

I did not find space in this abstract, but the Portlet 3 EG and Spec Lead
(IBM) seriously considers to tap into DeviceMap through the Portlet API.
To get an idea, there's another W3C recommendation, P3P ( which the Portlet API since 2.0 supports:
In a similar way, likely having to retrieve it via the already existing
CCPP extension:
(if that was too cumbersome, for the official JCP JSR referencing to other
accepted standards like W3C DDR I guess that's acceptable, see P3P, but the
Spec/API must not reference directly to an implementation like DeviceMap,
DeviceAtlas, etc. that's the rule for official standards;-)

Implementations like Apache Pluto may on the other hand use other Apache
projects like DeviceMap.
Having not only Apache Portals, but the Who is Who of Enterprise Portal
vendors (IBM, Oracle, Liferay, Red Hat/Exo or Vaadin just to mention other
EG members) use DeviceMap through the Portlet RI would certainly not harm
adoption and quite likely foster contribution to the device data, too.


On Wed, Jul 1, 2015 at 10:59 AM, Werner Keil <> wrote:

> There are at least a few Angular detection modules already on GitHub:
> or
> All of them I could spot use the "If/Else Spaghetti Code" notion somewhat
> similar to the likes of (at least in its Community Editions
> which are also available for free)
> Looking at just one of the biggest commercial names, DeviceAtlas:
> They pretty much sort supported languages by what they (and large portions
> of the industry) consider the order of importance:
>    1. Java
>    2. Node.js (JavaScript)
>    3. PHP
>    4. .NET
>    5. Python
>    6. Ruby
>    7. C/C++
> Actually Node.js is brand new (
> If we manage to support some (actually I believe Reza also wrote some C
> Classifier against OpenDDR earlier) or all of these in the order we're able
> to we can offer a good Open Source alternative to commercial closed-source
> products like DeviceAtlas, WURFL, etc.
> Oh and btw. shows,
> DeviceAtlas also offers JSON format of its data either as another option
> (for Java) or likely the default for Node.js, so DeviceMap "2.x" is simply
> another format to them. Which way the data is stored internally, one cannot
> tell for a closed-source vendor, so it's "some" format or DB and other
> flavors of the latest device data certainly gets transformed and converted
> between those formats. Paying customers who use some of its standard-based
> libraries won't be forced to use JSON now or rewrite the software to
> JavaScript or Node.js, they just get the same data based on their
> subscription.
> Btw. clearly states,
> DeviceAtlas not only uses the W3C DDR standard but some APIs (at least for
> Java) also leverage W3C CC/PP.
> Each of them has a target group and user base, so a diversity on the API
> side is beneficial. Same goes for the new "modular" approach we managed to
> find for DeviceMap.
> Guess I will also mention that in the abstract.
> On Tue, Jun 30, 2015 at 10:35 PM, Werner Keil <>
> wrote:
>> I'll try to condense it and factor into the abstract (with the 9k chars
>> available)
>> Some argue (not totally unjustified) huge Enterprise Portals are becoming
>> less important these days and the likes of Angular or Node.js work well for
>> many cases previously covered by big enterprise systems, either .NET or
>> Java EE. There is a point and if we support JSON natively those JS (where
>> it came from) solutions are probably a good thing to try include.
>> BrowserMap does not seem like a full JavaScript client or reusable API to
>> embed in a JS app on the server side.
>> However, I had a long call with the JSR 362 (Portlet 3) project whose RI
>> is under Apache Portals/Pluto too btw. Earlier Portlet standards also
>> included JSR 188,
>> Talking
>> about the notion of a "Device" or similar object allowing to tell a portal
>> which device the browser is running on would offer synergies with
>> DeviceMap, too. JSR 188 is pre Java 5, so the API looks pretty archaic,
>> maybe if the Apache Portlet project (RI) has some ideas beyond this JSR, it
>> would allow using DeviceMap.
>> Thanks,
>> Werner
>> On Tue, Jun 30, 2015 at 9:32 PM, Reza Naghibi <> wrote:
>>> I think its best to try and expand the horizons a bit. Server side device
>>> detection is an alright use case, but thats kind of in the past and its
>>> likely dead/dying. I think that most of devs are now just doing pure
>>> browser responsive css. I talk to very few people starting a new project
>>> based on device detection in 2015. My last 3 products were all responsive
>>> css, so that kind of says something. Also, given that browsers are
>>> supporting src sets and evolving device support everyday, this isnt a
>>> good
>>> vertical for us to position in. See my browser detection comment below.
>>> So here are a few things which are very relevant and devicemap can do
>>> really well:
>>> Analytics. This is a huge huge use case. Being able to batch classify
>>> traffic by device means a lot of things. It give you a sense of what
>>> devices are out there, the value of the device tells you something about
>>> economics of the users, etc. Being able to churn thru millions of
>>> devices a
>>> second means that you can quickly and easily analyze lots of data. This
>>> is
>>> pretty much standard analytics.
>>> Browser detection. This is something that is now going to be more
>>> important
>>> since browsers are getting better and better at normalizing for devices.
>>> Your code now needs to worry about the browsers.
>>> 2.0 domains. In 2.0, we are making classification generic, so people can
>>> introduce their own detection domains. This really expands what this
>>> project means and what you can accomplish. We will support lots of
>>> different languages, so you can now use your domain across a large
>>> ecosystem of clients. Js support is a big one.
>>> Im just concerned that aligning ourselves to device detection in 2015
>>> kind
>>> of does our work a disservice...
>>> On Tue, Jun 30, 2015 at 6:37 AM, Werner Keil <>
>>> wrote:
>>> > Dear DeviceMap team,
>>> >
>>> > As we just got about 24h left to submit proposals for ACE, please see
>>> last
>>> > year's (accepted) abstract they still have on record and kindly suggest
>>> > alterations or things to leave out if you think it's no longer needed:
>>> >
>>> > >
>>> > We experience a growing number of mobile phones, tablets, phablets,
>>> smart
>>> > TV and similar devices flooding the market almost every day. Capturing
>>> the
>>> > specification of each device is a tough job. If you want to create a
>>> > comfortable user experience you need dynamic content according to
>>> hardware
>>> > and browser specifications of your device. That’s the reason why Device
>>> > Description Repositories (DDR) exist. Apache DeviceMap is a
>>> collaborative
>>> > effort by Adobe, OpenDDR and others to create a comprehensive
>>> open-source
>>> > and open-data repository of device information, images and other
>>> relevant
>>> > information for all types of mobile devices, smartphones, tablets,
>>> smart
>>> > TV, etc.. The project began in January 2012, later that year OpenDDR
>>> > contributed DDR APis for Java and. NET. Ongoing steps are a common
>>> device
>>> > repository, a storage structure and maintenance of device data by the
>>> > Apache community.
>>> > >
>>> >
>>> > Of course it now graduated from the Incubator, that's a no-brainer, but
>>> > feel free to mention aspects of the 2.x vision if you want (max. 900
>>> > characters, the 2014 version got 892 already;-)
>>> >
>>> > I proposed at least one Groovy related talk already. And likely should
>>> be
>>> > co-speaker with Anatole and maybe others for Tamaya. I also make up my
>>> mind
>>> > about one proposal to the (larger) BigData one, something about Data
>>> > Quality and an Apache project that uses related APIs already...
>>> >
>>> > TIA,
>>> > Werner
>>> >

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