You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Werner Keil <we...@gmail.com> on 2015/07/01 10:59:33 UTC
Re: Call for Papers: "ApacheCON: Core" in Budapest October 1-2 2015.
There are at least a few Angular detection modules already on GitHub:
https://github.com/srfrnk/ng-device-detector
or
https://github.com/angular-adaptive/adaptive-detection
All of them I could spot use the "If/Else Spaghetti Code" notion somewhat
similar to the likes of 52Degrees.mobi (at least in its Community Editions
which are also available for free)
Looking at just one of the biggest commercial names, DeviceAtlas:
https://deviceatlas.com/resources/download-enterprise-api
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 (
https://deviceatlas.com/blog/deviceatlas-api-node-js)
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. https://deviceatlas.com/resources/getting-the-data 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. https://deviceatlas.com/resources/general 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 <we...@gmail.com> 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,
> http://www.oracle.com/technetwork/systems/index-155691.html 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 <re...@naghibi.com> 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 <we...@gmail.com>
>> 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
>> >
>>
>
>
Re: Call for Papers: "ApacheCON: Core" in Budapest October 1-2 2015.
Posted by Werner Keil <we...@gmail.com>.
Hi,
The schedule for both ApacheCon events is now taking shape. I also got the
ApacheCon Big Data talk approved, so in total I'm primary or co-speaker of
4 sessions:-)
Aside from the fact, it's the last talk of the conference week Friday
afternoon, the DeviceMap slot also looks good: http://sched.co/3x2Q
Having them put it under the IoT theme actually does not seem bad at all.
While devices to detect may mostly be tablets or phones, DeviceMap aims at
other device categories like Smart Watches or similar wearables or smart
appliances, so I don't see a problem with that. It might even keep a few
people from leaving despite the late timing;-)
Werner
Re: Call for Papers: "ApacheCON: Core" in Budapest October 1-2 2015.
Posted by Werner Keil <we...@gmail.com>.
All,
Happy to announce, 3 sessions for ApacheCon Core Europe 2015 were confirmed
to be accepted, 2 I proposed, another one as co-speaker. Including
DeviceMap.
While SlideShare also contains last year's ACE slides, a more up to date
version was used at codemotion Rome this spring:
http://www.slideshare.net/keilw/apache-devicemap-codemotion-roma-2015
Have a look, and happy about proposals for additional or modified pages. I
don't insist on every DDR synonym image (at least one still can't hurt I
guess) nor on every page referring to WURFL, except maybe the
performance/memory benchmarks. Anybody who helps the "Classifer" clients
either for Java or .NET perform better or has collected proper benchmarks,
please share them. Both the WURFL version and W3C DDR client tested are a
bit older now, though DeviceMap SimpleDDR should still provide similar
figures (and the WURFL version used was the last Open Source snapshot
available, so there is no new data there to trust or verify)
The open DDR comparison https://github.com/samaxes/ddr-compare will also
work against the W3C DDR version (since most of the code use the org.w3c
API;-) and it would be interesting to see, if one major painpoint [Nokia
E52 (Opera Mobile)] has been resolved by now. Similar to e.g. 51DegreeMobi
proprietary API, a test against the Classifier client should be possible,
feel free to fork the test suite if you want.
I already did demos of the .NET clients in addition to both Java clients.
Probably going to add more live demos, e.g. the GWT one presented on slides
only or maybe AngularJS, let's see. Aside from that synergies with Apache
Pluto and JSR 362 where that JSR deals with device support in EDR1 was also
an option. The outlook already mentioned ideas for the JSON format. I don't
expect a running client or example by late September, at least based on the
repository right now. If real device data was available in the
new/additional format by then, I'd gladly include a demo of it, too.
Regards,
Werner
Re: Call for Papers: "ApacheCON: Core" in Budapest October 1-2 2015.
Posted by Werner Keil <we...@gmail.com>.
OK, there is not much time left so I submitted the proposal with an updated
abstract:
>
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 (
http://www.w3.org/P3P/) which the Portlet API since 2.0 supports:
https://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/PortletRequest.P3PUserInfos.html
In a similar way, likely having to retrieve it via the already existing
CCPP extension:
https://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/PortletRequest.html#CCPP_PROFILE
(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.
Werner
On Wed, Jul 1, 2015 at 10:59 AM, Werner Keil <we...@gmail.com> wrote:
> There are at least a few Angular detection modules already on GitHub:
> https://github.com/srfrnk/ng-device-detector
> or
> https://github.com/angular-adaptive/adaptive-detection
>
> All of them I could spot use the "If/Else Spaghetti Code" notion somewhat
> similar to the likes of 52Degrees.mobi (at least in its Community Editions
> which are also available for free)
>
> Looking at just one of the biggest commercial names, DeviceAtlas:
> https://deviceatlas.com/resources/download-enterprise-api
> 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 (
> https://deviceatlas.com/blog/deviceatlas-api-node-js)
> 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. https://deviceatlas.com/resources/getting-the-data 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. https://deviceatlas.com/resources/general 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 <we...@gmail.com>
> 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,
>> http://www.oracle.com/technetwork/systems/index-155691.html 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 <re...@naghibi.com> 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 <we...@gmail.com>
>>> 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
>>> >
>>>
>>
>>
>