RE: Mobile phone capabilities list?

Thank you Luca. This also relates to a question I've been asked a few times regarding why MobileAware would consider an activity such as DDWG that might ultimately lead to MobileAware giving away part of its commercial device repository. The reality is that for the medium-to-small "two guys in a garage" operations, a solution like WURFL may be all they need, but for the major operations you generally have to look at the commercial products.
 
There are not many options in between, and there's certainly no compatibility across the gulf. But solutions like WURFL stimulate the market, make it possible for people to at least enter into this space and provide some Web service to the mobile community.
 
However, it seems to us that it would be better if the various technologies at all parts of the spectrum could work together, so that there is a clear migration path, consistent tooling, better scaling, etc. Skills learned working with WURFL would work with larger systems, tools for larger systems would work with small WRUFL-like deployments, the Open Source community would have greater scope because the environment is standardised and so on.
 
Meanwhile, MobileAware and others would be able to focus more on the value-add. Why spend time checking and rechecking the same basic device characteristics when this information should be generally available? There are more interesting attributes to consider, attributes that may be proprietary to particular adaptation solutions, for which it would make sense for the companies to expend effort measuring (and subsequently charging their customers for the use thereof). One could then access the validated base information from UAProf, some additional information from WURFL, some Device Independence information, some accessibility information, some usage guidelines, some preferred/localised layouts etc. All this through a single repository that facilitates the various contributors of information. Were such a facility in place, we in MobileAware would have no trouble contributing some of the baseline information. Doing so would stimulate the market because the general repository is enriched, while our higher-level proprietary information would subsequently gain in value. We could then focus on exploiting the entire collection of information in our content adaptation solutions. But right now, contributing anything to other solultions that are incompatible with ours is not something our company could consider.
 
So, please note that I am not criticising WURFL. I am merely hoping to find a way for WURFL and others to be part of a greater repository, in which everyone contributes (including WURFL, the contributors to the OMA UAProf repositories, and companies such as MobileAware, Volantis, Drutt and others) and which everyone can extend (including custom extensions for usage-specific requirements).
 
---Rotan (speaking on behalf of MobileAware)
 
-----Original Message-----
From: Luca Passani [mailto:luca.passani@openwave.com]
Sent: 22 July 2005 12:45
To: public-ddwg@w3.org
Cc: www-mobile@w3.org
Subject: RE: Mobile phone capabilities list?



 

Hi Tim, 

 

no problem about Bango not finding WURFL suitable for their needs. This is totally understandable, since WURFL is 
meant to be a solution for medium- and small-sized shops.

What brought me to create WURFL was my position with Developer Marketing at Openwave.

Obviously, promoting the Openwave WAP SDK was no longer much of an exciting story in 2002 for third-party developers,

so I figured out that I would either change job or become *very* proactive in addressing developer needs regardless

of the fact that I was on virtually no budget. 

My goal was to create a tool that would help "two guys in a garage" companies address what I had been perceiving

as the biggest problem in the industry since late 99: fragmentation of the browser market.

Andrea and I did a good job, since most people are pretty happy with it. 

Big companies (with large budgets) can always buy commercial products such as Volantis or Drutt in order to get 

the kind of "certified" device info their business model demands.

I am not arguing that WURFL data is good enough for everyone. It's good enough for most people and,

above all, easily fixable as soon as an error is found.  This makes WURFL popular. Improving on that would

bring WURFL beyond the objective it was born to serve: help content providers who already operate on small margins

(but which are very important for Openwave's ecosystem) to create more cool wireless apps.

 

WRT Microsoft mobile controls, I would argue that developers are not so extremely happy with it:

 

http://wurfl.sourceforge.net/voices/dotnetvswurfl.txt

-------------------------------------------------------------------------------

As a Microsoft-based developer (.NET, ASP,NET, etc), I can say without
a doubt that WURFL's steady growth and updates due to the community's
additions and patches puts this project in a far better position than
Microsoft's own adaptive rendering projects (ASP.NET, the .NET mobile
controls).  You can find workarounds that will allow ASP.NET to
recognize gecko browsers as being better than Netscape 4.7, but
Microsoft doesn't bother updating their browser capabilities section
themselves.   They actually point to Cyscape instead, saying that
Cyscape is in charge of maintaining the .NET browsercaps.  But the
page they point to on Cyscape's site has said "we're working on a new
version" since day one of .NET v1.0 (4 years ago).
 
So I have to hack up my own browsercaps sections for the .NET sites I
do just to get a decent HTML output sent to Firefox, I can't imagine
trying to keep up with mobile device updates...  
 
WURFL is a lifesaver.

-------------------------------------------------------------------------------

 

Maybe it wouldn't be a bad idea for Bango to embrace WURFL and help develop the testing framework and/or 

testing process which would make the framework serve your needs too. As an aside, we already have something along those lines:

 

http://www.ukmedia.us/i/

 

docs: http://www.ukmedia.us/i/docs/index.jsp

 

Luca

 

 [ .... see mailing list archive for previous messages ... ] 

Received on Friday, 22 July 2005 14:47:05 UTC