Hi Dave,
On Fri, Jun 1, 2012 at 3:40 AM, Dave Olsen <[email protected]> wrote:
> ...First off, thanks for highlighting my work with
> Detector. It's much appreciated...
You're welcome, and thanks very much for writing here - it looks like
we should be able to find ways to collaborate between the different
projects working in this space, even if we're targeting different
languages.
> ...Second, if there's any insight I can
> provide regarding the issues I've run into with Detector please let me
> know. It's great to see others pursuing similar lines of development.
> I'm really curious to see where it can be taken and if I can help...
As you probably noticed if you read our mailing list archives, this
project is just getting started, so I guess we're open to anything
that brings us forward - it can range from just discussing things and
sharing experiences to moving your code here (and becoming a committer
in the process of course) if that makes sense. Or maybe just sharing
the javascript detection code and related test suites so that they can
be applied to various server-side components. My current examples are
in Java because that's what I use in my work, but I think we should
abstract the client-side detection code as much as possible so that it
can be reused and shared between different languages.
> ...My feature detection code is just Modernizr. Any custom tests someone
> would want to develop can just use the Modernizr.addTest() Plugin API
> [1] so... maybe not so hard to implement ;) Though maybe those tests
> [2] are not enough info for your project...
I agree that the Modernizr stuff provides most of the information that
people need.
What might be interesting is defining a simple plugin system where
javascript snippets that detect more features (and/or cope with newer
devices) can be exchanged - but if possible it's probably better to
contribute such things to Modernizr instead of reinventing that wheel.
> ...For example, I noticed
> you're using the JS to get platform info via navigator whereas I'm
> going the more traditional route and using ua-parser [3] which was
> created with data from browserscope.org. Bryan, in developing Profile,
> was definitely trying to do something similar to your project. I'm not
> sure where he's at on that kind of thing. I don't foresee pulling away
> from Modernizr myself....
I think such choices should be left to the user - with devicemap the
aim is to provide reusable components and data that people can mix and
match according to their own needs and to which method they trust
best. A simple plugin system (like you have IIRC in Detector.js) is
probably good enough to allow people to do this mixing and matching.
>
> The plumbing definitely isn't hard. I'm more curious to see how the
> group determines what forms a base profile of tests that is useful to
> everyone. I'd be happy to see if I could standardize Detector on that
> set of tests too so data could be easily shared between projects...
> assuming this becomes a Java library (sorry, not sure what the
> deliverables for the project are)....
Yes, sharing those test sets would be great - maybe we just need to
base all tests on a simple plugin system that can be used from either
php, java or other languages? A textual javascript snippet definition
format that specifies dependencies ("Modernizr 1.3") and provides the
detection code might be sufficient.
> ...I'm probably being a little overbearing & longwinded... I wasn't quite
> sure how to introduce myself ;) So, hi :)...
Hi, and thanks very much for getting in touch!
-Bertrand
>
> [1] - http://modernizr.com/docs/#addtest
> [2] - http://detector.dmolsen.com/demo/modernizr-listing/
> [3] - https://github.com/tobie/ua-parser
> [4] -
> http://www.dmolsen.com/mobile-in-higher-ed/2012/01/18/introducing-detector-combining-browser-feature-detection-for-your-web-app/
> [5] - https://github.com/dmolsen/Detector
> [6] - http://ress.dmolsen.com
>
> --
>
> http://dmolsen.com
