I initially was quite happy to see a WURFL module for Drupal; the WURFL data is a great solution for device capability detection. But I decided to do some exploring of how other projects do device capability detection in PHP so that Drupal got the best solution possible.

What I discovered is that the standard WURFL PHP API is kind of crap and not very performant.
http://pointbeing.net/weblog/2009/04/a-first-look-at-the-new-wurfl-api-f...

Many PHP developers instead used a project called Tera-WURFL, which takes the WURFL data and puts it into a database so that it could deliver these goals to its users:

  1. High Performance: Tera-WURFL uses a database backend to store the WURFL data and cache the results of device detections.
  2. Accurate Detection of Mobile Devices: By using over a dozen UserAgentMatchers, specifically tailored to their own group of mobile devices, Tera-WURFL is constantly tweaked and tuned to provide more accurate results, detecting over 99% of visiting devices.
  3. Fast Detection of Desktop vs. Mobile Devices: Although detection of mobile devices is good among most of the libraries, they are not very good at desktop browsers. As a result, your desktop users are detected as mobile devices and sent to the wrong site. Tera-WURFL includes a feature called the SimpleDesktop Matching Engine that is used to differentiate between desktop and mobile browsers at an extremely high rate.

— from the Tera-WURFL project page.

#3 is not even something that the standard WURFL tries to handle. And #1 is a serious problem for the standard WURFL PHP API. Which, if I understand it properly, was the motivation for the failed WURFL module 6.x-2.x branch.

Instead of trying to write our own WURFL parsers and database storage (like WURFL module 6.x-2.x wanted to do), why not just use an existing proven solution and integrate it with Drupal?

I talked to the primary developer of Tera-WURFL and asked him about the separation between the standard WURFL PHP API and the Tera-WURFL API. He sees the two APIs as having separate goals, so it originally seemed fine to have 2 separate Drupal modules to support each of these APIs. (One module with optionally support for 2 different library APIs seemed like a disaster waiting to happen.) And I started working on a tera_wurfl module in a sandbox. http://drupal.org/sandbox/johnalbin/1168218

(Side note: Tera-WURFL was using MPL which is incompatible with the GPL, but it got converted to a new license yesterday after I asked about that.)

However, yesterday the Tera-WURFL project was renamed to be the “ScientiaMobile WURFL API: Database Edition". No, I’m not kidding. Needless to say, I'm not going to name the module I was writing scientiamobile_wurfl_api.module. :p

Personally, I think the originally-Tera-WURFL API is way better then the existing API that the WURFL module uses. So I don't see a reason to support the old, slower file-based API.

So I was wondering if you wanted to toss out the unfinished 6.x-2.x branch and start over in Drupal 7 to use this new database-driven API?

I'm going to work on the new API regardless, but I think it would make more sense for the community if I folded my work into your project.

Comments

chiebert’s picture

chiebert commented

I'm certainly interested in a faster, more accurate detection method to power responsive designs, and I'm most certainly interested in a D7 module to accomplish this. Watching with interest, and willing to help test/tweak/contribute as I'm able.

joekrukosky’s picture

joekrukosky
Primary language English
Location Crystal River, FL
commented

Subscibe

Anonymous’s picture

Anonymous (not verified) commented

subscribe

bayousoft’s picture

bayousoft commented

John's idea sounds like the proper solution to me.

senortim’s picture

senortim commented

Voting for John's idea.

twom’s picture

twom commented

Hi John,

Thank your for taking this initiative. WURFL performance has been an issue... However, using the memcache configuration of WURFL performance increased dramatically.

However, as you mention, Tera-WURFL seems to be the new and faster solution... I would assume that the combination with MongoDB, shared for several websites could be a great solution. So I would agree that making a better integration with Drupal would be great.

The current WURFL-6.x-2.x branch was indeed very experimental and I don't see any problems with replacing it with a new solution.

So, how would you like to proceed? Do you want to continue on your sandbox, or would you like to start working on the 6.x-2.x branch in the official project? I can add you as co-maintainer.

kevin-bcr’s picture

kevin-bcr commented

Subscribe

himerus’s picture

himerus commented

subscribe

MarcGuay’s picture

MarcGuay commented

It should be noted that the licensing of the WURFL APIs has changed. See http://tech.dir.groups.yahoo.com/group/wmlprogramming/message/34031.

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented

Oh, July… where did you go?

Hi Tom,

I'd love to start working in this project's repository as a co-maintainer rather than continuing in my sandbox! :-)

I'll leave the 6.x-2.x branch alone (abandoned?) since my work is based on D7.

johnnygamba’s picture

johnnygamba commented

suscribe

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented
Version: 6.x-2.x-dev » 7.x-2.x-dev

Ok! Tom made me a co-maintainer and I pushed my changes to a new 7.x-2.x branch.

himerus’s picture

himerus commented

John...

Finally chiming in here on the 7.x-2.x version you've started on... Is it stable enough to start working with and testing/helping out??

I think WURFL (and the faster, more reliable database version) are going to play a huge role in my upcoming work...
I'm curious to see where the module is going as I need to (either help or contribute as it's own project) a context integration that will allow for switching (using Delta module) the content rendered on the page based on the device type (screen capabilities)...

My end goal is folding it all into the currently responsive core of Omega to compliment the already easy layout changing via context w/Omega & Delta to also include different region layouts & content based on the size of the target browser.

bneil’s picture

bneil commented

My end goal is folding it all into the currently responsive core of Omega to compliment the already easy layout changing via context w/Omega & Delta to also include different region layouts & content based on the size of the target browser.

+1 to this! That's essentially what my coworker was suggesting in #1244222: Adjust block placement based on "Mobile" width. We're planning on using Omega for our University-wide D7 roll-out and the ability to do this somehow with Omega/context will be essential for us to add global header/footer blocks on wide widths while keeping our narrow widths free of these blocks.

I'm in for any testing or help I can provide with WURFL/Omega/Delta/Context to achieve this functionality.

lebeaui’s picture

lebeaui commented

Subscribe

himerus’s picture

himerus commented

This is definitely in my roadmap.

All the conversations I've had leading up to, and including at DrupalCon London from shop owners/decision makers lead up to this functionality... in one form or another it HAS to happen.

While the "true definition" of responsive is NOT one that changes the content based on screen size, it STILL IS a required feature as described by yourself.

The combination of Omega/Delta/Context/WURFL/*WURFL Context Bridge* (possible name) could easily accomplish this. :)