Structure description

Mar 21, 2009 at 9:49 PM
Edited Mar 21, 2009 at 9:50 PM
First of all~2c thanks~21 This file was loooong overdue. ~3a~29 I guess a lot of people will be grateful for that.~3cbr /~3e ~3cbr /~3e It would be nice if you could describe the structure ~28and the rationale behind it~29 of the file -- how you segment the devices and why is it done in such a way. I see there is a lot of inheritance~2c but it is quite hard to modify the file and change it so that the values can be modified. The hard part is the finding of the device.~3cbr /~3e ~3cbr /~3e Also~2c is there a way to load this file in a console application and try outside of ASP.NET context~3f Like feed it request headers and see how the Request.Browser would get populated~3f That would be very useful for ~22client issue~22 resolution~2c when users complain that they didn~27t see this stuff as they should have.~3cbr /~3e ~3cbr /~3e Thanks~21~3cbr /~3e
Mar 21, 2009 at 9:51 PM
Apparently~2c there~27s something wrong with the editor...~3cbr /~3e
Mar 23, 2009 at 2:29 PM
Thanks for your question skyflyer. We hope people will find this file useful.

Take a look at the Browser Definition File Schema MSDN article. It has quite detailed information about how the file is structured and how it gets processed by ASP.NET. In short, the .browser file represents a tree structure where the nodes match regular expressions against HTTP headers.

Manual modification of the file isn’t actually a scenario we’ve designed for. The file is programatically generated and your changes will probably be overwritten by future releases. Indeed, the structure of our .browser format is liable to change, but I can describe how it works currently. We use the tree structure to form an inheritance hierarchy, as you gathered, where capabilities for a particular device are inherited from defaults to the manufacturer to the model and (possibly) to the version of the device (e.g. defaults > SonyEricsson > k800 > i). We have a similar hierarchy for the web browser the user is running.

Could you give us an example of how you might want to edit the file? If it’s something that might be relevant to the rest of the community, like correcting a capability value, we'd love you to submit a bug for us so we can include a fix in future releases of the file. If it’s not something you think other people will care about, rather than editing our file, you can create your own .browser file(s) that will extend our data (see the MSDN article).

To check what capabilities will get returned for a given HTTP request, we suggest setting up a simple web page that list all the capabilities and their values (see the Request.Browser.Capabilities property). You can then go to this web page with the User-Agent (and other headers) in question and see what comes out. To manipulate the request headers you could use Fiddler or the User Agent Switcher Add-on for Firefox.
Mar 23, 2009 at 4:49 PM
Since the above answer is barely readable, I'll try to post this from a Windows machine. :)
 I've been working with mobile sites for a while, and used mostly WURFL, but also .dotMobi DeviceAtlas. Before those, we used MobileAware. We were handling mobile sites with a demanding SLA (all of the devices on the market had to be supported). So, most (all actually) of the device databases are incomplete and certain capabilities differ among them -the video capabilities are especially poorly populated because they are complex and time-consuming to test). Also, the MDBF does not contain older, but still relevant devices like SE T610i.
 So, in order to offer the best possible experience for the end users, we end up modifying/editing (patching) the device database. We do it regularly with WURFL, for instance, where we introduce patch files, which "override" the values in the regular distribtion. That's why I'm asking how to edit the database~3f Of course, people will submit "bug" reports, but they will also want the data ASAP.
 Another, also very interesting approach we've made (note that this tool is very old and obsolete right now) is a device-detection-test utility, which tests the device browser interactively and automatically populates the device database with the data. You can see a demo here: -this is ASP.NET + WURFL API + WURFL XML). The tests automatically set the properties in a "patch" file, which is "merged" with the real configuration in runtime.
 As for the "console app" approach, I'm mainly interested in an API towards MDBF. How can I load MDBF programatically (maybe outside of ASP.NET) and parse it, test it, and so on. You can imagine, it is much easier to do this using the console app and an MDFB API, and say compare/dump values for a lot of devices. For instance, with WURFL library, we used not only for rendering adaptaion, but also to parse IIS access logs and use that data for statistics -how many devices with screen > 200px access the site) and so on.
 Thanks for the MSDN pointers, I've read the article.
 Any thoughts on enabling the "plugging in" of MDBF in a "provider model" fashion. Like Membership API/Caching/Session for instance.
Mar 25, 2009 at 10:54 AM
"Also, the MDBF does not contain older, but still relevant devices like SE T610i."
The file contains devices that make up about 80% of the traffic we see on sites like Hotmail. If there's a device you think important that we've missed, please file an issue specifying the device manufacturer and model name, an example User-Agent string and, if possible, a User Agent Profile URL and we'll attempt to support it in a future release. It would also help if you could add information about the device, any markets or countries where the device is popular, or, if it is a new device, where or when it's getting launched first. All this information helps us in selecting the most important issues that we should tackle first.
"That's why I'm asking how to edit the database. Of course, people will submit "bug" reports, but they will also want the data ASAP."
We understand your need here. Directly editing the file isn't recommended since the structure is subject to change. The best possible way to extend the dataset is to add your own .browser file(s) to another directory in the App_Browsers folder. This .browser file will get parsed in parallel to the MDBF file and allow you to add devices or capabilities that we don't support. You can find documentation for writing .brower files in the MSDN article.
"As for the "console app" approach, I'm mainly interested in an API towards MDBF. How can I load MDBF programatically (maybe outside of ASP.NET) and parse it, test it, and so on."
The .browser file uses with the standard ASP.NET framework and I don't believe there is currently an API for its use outside of ASP.NET. Perhaps the best way to retrieve the data in a command line form would be to construct a tool that would utilise the simple ASP.NET web page I mentioned in my last post.

I hope this is of some help to you,