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 <[email protected]> Date: Mon, 1 Jul 2013 11:05:46 To: devicemap-dev<[email protected]> Reply-To: [email protected] 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 <[email protected]> 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/> >
