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 Tue, 30 Jun 2015 20:35:24 GMT
I'll try to condense it and factor into the abstract (with the 9k chars
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.


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