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/
