You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Radu Cotescu <ra...@apache.org> on 2013/07/01 10:05:46 UTC
Re: feature proposals after java user group meeting
Hi Reza,
BrowserMap can do both things [2]. It actually relies on several features
of the client to try to establish the device group the client belongs to.
We could for example run a service where BrowserMap does the detection and
the server-side part of the app just stores the detected features
associated to a User-Agent string. :)
We've successfully been using BrowserMap in Adobe CQ / AEM to perform
detection. Therefore I don't know why you'd limit client-side detection
only to "autoplay videos on desktop browsers". BTW, I hate it when websites
do this to me and I don't know which tab started the chaos.
HTH,
Radu
[2] - http://raducotescu.github.io/browsermap/index.html
On Fri, Jun 28, 2013 at 2:53 AM, Reza <re...@yahoo.com> wrote:
> hey Radu, you bring up some good points:
>
> a service ... to gather data in order to improve the server-side
>>> detection accuracy
>>>
>>
> Yes, this is something that would be of great benefit. This was what I was
> trying to start earlier in the project by building a website to allow for
> user submitted devices, bugs, and errors. I would like to continue work on
> this. How much of this can be automated and how much requires human
> interaction? Not sure...
>
>
> tighter integration between the server-side module and the client-side one
>>>
>>
> I have been thinking about this too. So I would like to better understand
> the use cases for some of this. To answer my own question:
>
> -device classification at the routing/caching level, ie: varnish, apache,
> nginx
> -allows for device and resource routing, rewriting, redirection
> -plays well with caching, so very high performance, especially if you
> don’t want to hit your backend everytime
> -backend and frontend can leverage this via Headers and Cookies
>
> -device classification at the backend application level, ie: Java, .NET,
> PHP, Python
> -can be embedded into the app, so easier to integrate
> -can be used to drive custom views and per device logic
>
> -frontend device classification, ie: Javascript in the browser
> -had one use case where we wanted to autoplay videos on desktop
> browsers, but not phones or tablets.
>
> What are some other use cases for frontend device classification? How does
> this play with feature detection? Does browser map do feature detection?
> Feature detection to me is a very different animal than device
> classification.
>
> simpler api
>>> custom fallback code
>>> flexible loading
>>>
>>
> I think we are in a good position to deliver on all of these points. Im
> actually surprised a lot of people are wanting this level of customization.
> I lot of the web devs I have talked with just want a drop in solution with
> no configuration. I think we can definitely satisfy both.
>
>
> frequent updates to the datasource files
>>>
>>
> Yes... this part has me a bit concerned.
>
> -----Original Message----- From: Radu Cotescu
> Sent: Thursday, June 27, 2013 6:24 PM
> To: devicemap-dev
> Subject: feature proposals after java user group meeting
>
>
> Hi,
>
> The Bucharest Java User Group meeting no. 13 finished a few hours ago and
> the attendants seemed quite curious about Apache DeviceMap - my slides can
> be viewed at [1]. Although the talk was supposed to last around 30 minutes
> we reached to one hour due to quite a few thoughtful questions.
>
> Among the features that the community expected to be provided by DeviceMap
> were the following:
>
> - tighter integration between the server-side module and the client-side
>
> one - by this they were referring to some coherence between the device
> groups from BrowserMap and a similar concept in the DDR code so that they
> could have 1:1 OOTB mappings between the two detection modules' results
> - simpler API for performing a detection query using the ODDRService (no
>
> PropertyValue, PropertyRef and co) or the like; I already told them about
> Reza's efforts for the Java module and people were excited; they also
> seemed to agree on the fact that the flexibility provided by the
> ODDRService of accepting file system paths or input streams for
> initialising the repo is a cool feature given the multiple ways of
> storing
> data these days
> - the ability to plug some custom code for detection fallback into the
>
> server-side code - similar to the probing mechanism provided by
> BrowserMap
> - frequent updates to the datasource files
> - a service built on top of BrowserMap and the server-side detection
>
> modules to gather data in order to improve the server-side detection
> accuracy
>
> Out of all the last point seems like a cool little project by itself. I've
> also advertised the fact that we're still looking for committers so maybe
> some of them will join our project.
>
> WDYT about these proposed features?
>
> Thanks,
> Radu
>
> [1] - http://radu.cotescu.com/talks/**2013.06.27_BJUG13/<http://radu.cotescu.com/talks/2013.06.27_BJUG13/>
>
Re: feature proposals after java user group meeting
Posted by Reza Naghibi <re...@yahoo.com>.
Well, my question was more along the lines of what are some of the user cases of knowing the phone features in a browser?
---
Sent from a Blackberry 9900
-----Original Message-----
From: Radu Cotescu <ra...@apache.org>
Date: Mon, 1 Jul 2013 11:05:46
To: devicemap-dev<de...@incubator.apache.org>
Reply-To: devicemap-dev@incubator.apache.org
Subject: Re: feature proposals after java user group meeting
Hi Reza,
BrowserMap can do both things [2]. It actually relies on several features
of the client to try to establish the device group the client belongs to.
We could for example run a service where BrowserMap does the detection and
the server-side part of the app just stores the detected features
associated to a User-Agent string. :)
We've successfully been using BrowserMap in Adobe CQ / AEM to perform
detection. Therefore I don't know why you'd limit client-side detection
only to "autoplay videos on desktop browsers". BTW, I hate it when websites
do this to me and I don't know which tab started the chaos.
HTH,
Radu
[2] - http://raducotescu.github.io/browsermap/index.html
On Fri, Jun 28, 2013 at 2:53 AM, Reza <re...@yahoo.com> wrote:
> hey Radu, you bring up some good points:
>
> a service ... to gather data in order to improve the server-side
>>> detection accuracy
>>>
>>
> Yes, this is something that would be of great benefit. This was what I was
> trying to start earlier in the project by building a website to allow for
> user submitted devices, bugs, and errors. I would like to continue work on
> this. How much of this can be automated and how much requires human
> interaction? Not sure...
>
>
> tighter integration between the server-side module and the client-side one
>>>
>>
> I have been thinking about this too. So I would like to better understand
> the use cases for some of this. To answer my own question:
>
> -device classification at the routing/caching level, ie: varnish, apache,
> nginx
> -allows for device and resource routing, rewriting, redirection
> -plays well with caching, so very high performance, especially if you
> don’t want to hit your backend everytime
> -backend and frontend can leverage this via Headers and Cookies
>
> -device classification at the backend application level, ie: Java, .NET,
> PHP, Python
> -can be embedded into the app, so easier to integrate
> -can be used to drive custom views and per device logic
>
> -frontend device classification, ie: Javascript in the browser
> -had one use case where we wanted to autoplay videos on desktop
> browsers, but not phones or tablets.
>
> What are some other use cases for frontend device classification? How does
> this play with feature detection? Does browser map do feature detection?
> Feature detection to me is a very different animal than device
> classification.
>
> simpler api
>>> custom fallback code
>>> flexible loading
>>>
>>
> I think we are in a good position to deliver on all of these points. Im
> actually surprised a lot of people are wanting this level of customization.
> I lot of the web devs I have talked with just want a drop in solution with
> no configuration. I think we can definitely satisfy both.
>
>
> frequent updates to the datasource files
>>>
>>
> Yes... this part has me a bit concerned.
>
> -----Original Message----- From: Radu Cotescu
> Sent: Thursday, June 27, 2013 6:24 PM
> To: devicemap-dev
> Subject: feature proposals after java user group meeting
>
>
> Hi,
>
> The Bucharest Java User Group meeting no. 13 finished a few hours ago and
> the attendants seemed quite curious about Apache DeviceMap - my slides can
> be viewed at [1]. Although the talk was supposed to last around 30 minutes
> we reached to one hour due to quite a few thoughtful questions.
>
> Among the features that the community expected to be provided by DeviceMap
> were the following:
>
> - tighter integration between the server-side module and the client-side
>
> one - by this they were referring to some coherence between the device
> groups from BrowserMap and a similar concept in the DDR code so that they
> could have 1:1 OOTB mappings between the two detection modules' results
> - simpler API for performing a detection query using the ODDRService (no
>
> PropertyValue, PropertyRef and co) or the like; I already told them about
> Reza's efforts for the Java module and people were excited; they also
> seemed to agree on the fact that the flexibility provided by the
> ODDRService of accepting file system paths or input streams for
> initialising the repo is a cool feature given the multiple ways of
> storing
> data these days
> - the ability to plug some custom code for detection fallback into the
>
> server-side code - similar to the probing mechanism provided by
> BrowserMap
> - frequent updates to the datasource files
> - a service built on top of BrowserMap and the server-side detection
>
> modules to gather data in order to improve the server-side detection
> accuracy
>
> Out of all the last point seems like a cool little project by itself. I've
> also advertised the fact that we're still looking for committers so maybe
> some of them will join our project.
>
> WDYT about these proposed features?
>
> Thanks,
> Radu
>
> [1] - http://radu.cotescu.com/talks/**2013.06.27_BJUG13/<http://radu.cotescu.com/talks/2013.06.27_BJUG13/>
>