This is Cranstone's Typepad Profile.
Join Typepad and start following Cranstone's activity
Join Now!
Already a member? Sign In
Recent Activity
My definition of rich - when you don't let you wants get ahead of your needs. Because then you have "enough".
I think this article is spot on. How about another way of looking at the same problem? Show us something that Oil/Energy "doesn't" play a role in (that we consume). Energy is at the core level of everything we as humans do. The second law of thermodynamics comes to mind here. We've already hit peak oil, what happens from here on out is pretty simple even for the non intellect to grasp - as things become more scarce the price goes up.
>> build a better online identity solution than creaky old HTTP cookies. We did. 5o9 Inc. Cheers, Peter
Toggle Commented Nov 14, 2010 on Breaking the Web's Cookie Jar at Coding Horror
Agreed. You asked a question and I gave way too long an answer which crossed the line. Sorry about that. As for the sensor api. It's an API that allows widgets (not the same as a browser) to retrieve and manage information about sensor channels on a device. Guess what - it doesn't work on the other platforms. So now I'm back to square one - HTML5 for some things, JavaScript for others, widgets for others, apps for others. It's not a sustainable business model. HTML5 is going to be the closest there will be to a solution that doesn't involve some sort of client work. And once you get used to working in the browser you're not going to want to hire mobile programmers to build and rev apps. Here's an interesting post for you. App is crap, why Apple is bad for your health. - sums things up pretty well Goodnight :)
Toggle Commented Mar 16, 2010 on Breaking user-agent news at Tom Hume
Tom, One more follow up. Just reading about the device specs for the WinPho7 - see below 800×480 screen (320×480 to follow) 256MB RAM, 8GB flash storage 4-point multi-touch ARMv7 Cortex/Scorpion or better DirectX9 support by GPU Codec acceleration (probably on GPU via DirectX) 5 megapixel camera with flash and separate camera button Three hard buttons: Start, Search, and Back GPS, accelerometer, compass, light and proximity sensors The first and last are important - all kinds of sensors are going to be added to these devices and the screen size and resolution is going to be all over the map. Building mobile apps cross platform is going to become cost prohibitive. Which leaves the browser as the way to go. This brings us full circle back to the very problem you talk about - device capabilities. No way JavaScript is going to tell you about the sensors and other items (SIM cards, Processor ID etc). And User Agent will not be able to keep up with all the new things that are going to appear in the next 5 years. There is no silver bullet in mobile. Ours is one approach that solves the problem. Others will likely appear. It's a mess out there. Cheers, Peter
Toggle Commented Mar 15, 2010 on Breaking user-agent news at Tom Hume
WM 5.0 and above, Blackberry 4.02 and above, All versions of Android, iPhone and iPad, Symbian S60. Not sure on the exact percentages, but a reasonable number. IMHO it's not just about identifying the screen width and height through client side scripting. It doesn't supply enough context to deliver a great experience and drive net new revenue opportunities. How many times have you had to type in a user name and password? Cookies don't work and they certainly don't support privacy. HTML5 is meant to be the great savior, but how many phones will support it correctly. What we wanted was 100% accuracy on every request and we got it. There is no need to interrogate the device, you know ahead of time which is exactly what you need. Sending down a request to figure out something is a waste of bandwidth. Where our approach really shines is cross platform. Most people can support one platform, maybe two. Ours runs on everything (caveats already listed). Need a sensor data encrypted from your phone along with lat/long/speed and few other things. It's simple to do. It seamlessly integrates with your Web apps with nothing new to learn. There's no substitute to knowing ahead of time - as your blog mentions the alternative is the continuous updating of online databases with device profile information. Do we leave a lot of devices "off the table so to speak?" Yes. Can't be helped. We had to look to the future. There's no going backwards now. It's all about smarter data plans, smarter browsers and smarter phones. It will start in the Enterprise and then migrate to the Consumer. Cheers, Peter
Toggle Commented Mar 15, 2010 on Breaking user-agent news at Tom Hume
One other comment to bring this thread full circle... at the end of your blog you wrote... "Or do we use some other mechanism to determine device capabilities?" We have another mechanism to solve this problems.
Toggle Commented Mar 15, 2010 on Breaking user-agent news at Tom Hume
What I should have said when making the statement that it's available for all platforms is the following - the mobile platform must support a HTTP connection via a browser and the OS must allow for the addition of third party applications. If not then we don't work. Sorry about the confusion. Going forward I see this as a significant part of the future for mobile. I'll check on the S40 series - but the above caveat will apply.
Toggle Commented Mar 15, 2010 on Breaking user-agent news at Tom Hume
A browser filter also known as a mime filter, or a browser plugin. An example is "NetNanny" which installs as part of your browser and allows you to filter certain URL's from loading. Also think of it as an app... so as long as the Nokia 6230i supports the ability to load an app then you can install a browser filter (app). With our solution there is no configuration, it all runs in the background. The database app which stores the real time meta data simply talks to it anytime the browser gets a web page request. Database (app) sends data to ---> browser filter (app) which appends it to the outgoing HTTP request headers which goes to the ---> web server where they are read by a script. You can then use CGI to pass the data ---> to a web app server
Toggle Commented Mar 15, 2010 on Breaking user-agent news at Tom Hume
>> how does the "jumping in" work? We use a standard browser filter and as the request leaves the browser we simply stop it and add the new meta content (if there is any to add, if not we don't stop the transmission) >> I can imagine lots of applications for such a thing (and plenty of security risks too)... Let's talk about the security issues first. When we started we met with prospective clients both on the Enterprise side and also the Consumer. The consumer (mobile user) wanted three things: 1) Convenience 2) Privacy 3) Control Nothing happens unless the user first enables it. In fact we've been caught a few times doing tech support when programmers can't see the headers. We suddenly remember that unless you have added to your approved domain list nothing happens. Also people wanted granular control over what they shared that was personal. So for instance I can share my zip/postal code but not my real time lat/long. Or vice versa. Or as I trust the web service I can share more data that drives relevance. Also we added a set of Open API's. Let's say that you have a mobile app that uses some proprietary encryption - you don't want to share those algorithms with anyone. No problem. You encrypt the meta data and then hand it over to us via the API and we add it to the HTTP request headers. It arrives at the other end (web server) and all you do is have a script that reads it and then passes it to an engine that does the decryption. On the Enterprise side we learned that they wanted three things... 1) To make money via "net new revenue opportunities 2) Nothing new to learn - they wanted to use their existing programmers and their toolsets (perl, python, php, javascript etc) 3) Zero integration issues - we solved this by taking something that they already like mod_gzip and turning it into mod_mobile. All you need is a single line in your config file to run it When we started we approached the problem from the standpoint that the web that we currently know in the future will be the web that knows me. There is nothing sinister in this - we just don't see people typing anything on these devices. Or if they do it's minimal. What we wanted was a way to overcome the limitations of the device, small keyboard, no mouse and tiny monitor. This allows you to do everything without the need to enter data. Finally it also allows you to offer new services based for example on sensors that attach to a mobile device. A blood pressure monitor connected by bluetooth sends "meta data" to an app on the device. You can then share this data in real time via our solution and you don't have to worry about encryption or privacy etc. Cheers, Peter
Toggle Commented Mar 15, 2010 on Breaking user-agent news at Tom Hume
You're not being slow at all. It takes a few tries before everyone gets their head around it. >> What HTTP header fields is the browser adding into the HTTP request I'm making? The ones that are in the database. (the mobile app that sits on the device). For example it might be, carrier, cell tower id, lat, long, speed, browser height, browser width, my name, address, email address, zip code, likes, ad preferences. Basically it's a fully customizable database. All of these "headers" and the associated meta data can now be added in real time to the HTTP request. >> And how is your software persuading the S40 browser to modify its HTTP headers in the first place? We're not :) What we do is "jump in" as the browser sends the request to and for a split second we hold it up and ask the mobile app if it has any meta data for that domain. If so, we add it. If not we release it. (This all takes about a nano second). >> I'm struggling to see how you'd alter the behaviour of a web browser on devices where there are no third-party native apps allowed. You're correct here. If the device does not allow third party apps then our solution doesn't apply "unless" we work with the OEM and they include our software on the device.
Toggle Commented Mar 15, 2010 on Breaking user-agent news at Tom Hume
The browser does it for you. Here's the deal... on your Nokia 6230i you open up the browser and navigate to a web site, Inside that web page request is all the meta data that tells you what the device is capable of doing in real time. Go to this site: and you can click on the Symbian link and see it running on an N97. Same principal applies to the other phones. The dependency is an HTTP browser and a connection to the web.
Toggle Commented Mar 15, 2010 on Breaking user-agent news at Tom Hume
You don't need client side scripting - only server side. The data is pushed to the server, not read from the device. That's the beauty of it. The meta data (Device Capabilities) becomes part of the web page request. Doesn't require any effort or anything fancy on the client. Although for those who only want to use JavaScript we have a solution we call JSAPI (pronounced j-sappy). This allows you to use JavaScript in your web page to access device side capabilities (assumes that the user gives you permission). To see what the code looks like go to this page: and right click and view source. It's all there. Cheers, Peter
Toggle Commented Mar 15, 2010 on Breaking user-agent news at Tom Hume
Hi Tom, You already figured it out :). Here's how it works. We have a database that sits on the mobile device (a mobile app if you will). It collects meta data from the device. We break it down into three buckets... Who, What and Where. For What and Where we simply read any device side API that we want the meta data from. This along with personal information added by the user gets stored in the database. The database can be encrypted and also every piece of meta data is under the control of the user. (In addition the meta data can be encrypted in transit for additional protection). What happens next is straightforward. Part of Mobile app contains a browser plugin that essentially adds the meta data to the HTTP request headers when I navigate to an approved domain (also under the control of the user). It adds it via the W3C approved X header format. So for example a header might be HTTP_X_TOM_HUME_LATITUDE="meta data goes here". Now as you've already figured out all I have to do at the server is use a script to read the incoming headers and the data inside them. It conforms to all approved standards and allows you to know in real time what the device is capable of doing without looking anything up. We're the inventors of mod_gzip, so we took that which is already IT approved and turned it into Mod_Mobile. It now supports real time data compression using both gzip and bz2 and also real time decryption of the incoming content. There's lots more information on our web site ( including free trial versions. You don't need anything on the server to see it work. Just a script to read the incoming headers. After that you can do whatever you want with the data. We also have introduced something called contextual menus inside the browser. Think of this as nav links that can be coded in HTML but show up in the browser menu for quick navigation like a mobile app would do. Except you can do it with a single line of HTML. BTW we run on iPhone, Symbian, Blackberry, Windows Mobile and Android and on the server side (if you need the encryption/content acceleration) we support IIS and Apache 2.x.x Cheers, Peter.
Toggle Commented Mar 15, 2010 on Breaking user-agent news at Tom Hume
Cranstone is now following The Typepad Team
Mar 15, 2010