devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: Call for Papers: "ApacheCON: Core" in Budapest October 1-2 2015.
Date Wed, 01 Jul 2015 08:59:33 GMT
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 <werner.keil@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 <reza@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 <werner.keil@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
>> >
>>
>
>

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