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/06/28 00:24:17 UTC
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/
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/>
>
Re: feature proposals after java user group meeting
Posted by Radu Cotescu <ra...@apache.org>.
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 <re...@yahoo.com>.
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/