Before embarking upon a discussion about the practicalities of developing mobile websites, let ’s
think about some of the opportunities that a mobile web brings and how it should encourage you to revisit many of the assumptions you may have made about today ’ s desktop web.
New places: Whether it ’ s on a train, waiting in line at a bus stop or an airport, walking down a street, working in the fields, lounging on the beach, or snatching glances while driving a car, humans now have the opportunity to access websites from a whole host of new locations — places where it is impractical or impossible to use a desktop or laptop computer. The desktop web gets used from home, the office, and possibly café s and kiosks, but places and situations where users can access the mobile web are innumerable. Think how you can adapt your services and content to cater to people visiting your site from these novel contexts, and with the rise of geolocation capabilities in some modern browsers, you can even start to key your content off them.
New users: The mobile web creates the opportunity to place web content into the hands of new users altogether. It is easy to think that everyone has regular access to a computer connected the Internet, and in some developed markets and for certain demographic groups, that ’ s true. But the availability of fi xed Internet access is already dwarfed by that via mobile devices. The International Telecommunications Union (ITU) estimates that there are 13.6 mobile 3G subscriptions for every 100 people (compared to 8 fi xed broadband connections). But even that is just the start: Only 1 billion of the world ’ s 5.3 billion mobile subscribers have 3G connections. If that proportion grows rapidly over the current years, there will be literally billions of new mobile web users around the world. Suffice to say that this sheer volume can be a huge opportunity for site owners to capitalize on.
New marketing, new business models: The mobile web provides a new way to reach potential
and existing customers. If you run an online business, or an offline one that relies on online marking and promotion, this can significantly open the possibilities for you to grow and
develop your business. Through localized and targeted mobile advertising, you can reach users who are perhaps more in need of your services than ever (a web search for “ plumber ” on a mobile device might imply that the user is in more urgent need of service than from a high - and - dry desktop browser!), and location - based social networks providing check - in functionality (such as Facebook, foursquare, and the like) look set to offer exciting new ways to promote and market certain types of businesses. But the mobile medium itself provides the opportunity for new fulfillment and business models altogether. From phone - based voucher techniques, to games with in - app purchasing, to near - field communication - based commerce, the mobile device offers new ways to interact with customers and create business opportunities.
New types of relationships: Often overlooked is that fact that the mobile web is a medium viewed through the screen of what many consider to be a highly personal piece of consumer electronics. With them all the time and normally held close to their body, the mobile phone is more to many users than simply another gadget: It is their primary link with their friends, their families, and their online lives. A computer rarely engenders as much love and care as a mobile phone, and many believe that this can be an important facet to consider when developing mobile web services. Bland, impersonal web pages might jar with a user ’s perception of what his mobile device represents; he may expect the mobile web to be more immersive, more customized, more personal, and more social. As a site owner, you need to consider how your online presence can capitalize on this more emotional relationship between the user and the medium.
One final point is arguably more important than all of these, and it ’ s one that sows the seeds for
you to be able to really explore the possibility of the mobile web: The mobile phone is so much more than simply a piece of hardware upon which a lonely browser runs. Today ’ s mobile devices are truly the Swiss Army knives of modern society: a phone, an address book, a calendar, a camera, a music player, a compass, a messaging terminal, a game console, and now a web client.
Even if it simply results in ensuring that your business website has a click - to - call link with your telephone number (so the user can dial you straight from the page), keeping this fact in mind is an important step in crafting the shape of this new medium. Using geolocation; allowing social media interactions with users ’ friends and contacts; uploading photos directly from a camera; building web applications that respond to phone orientation, temperature, light levels — the list of ways in which a mobile device could be a more capable web client than a desktop one is almost endless. It ’ s true that this is still an area of much standardization work (privacy and security are important considerations, of course). But what is truly exciting about the potential of the mobile web is that you have barely glimpsed at the possibilities gained by aligning web - based services with the diverse capabilities of these amazing little devices.
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
A NEW MEDIUM
So what is this mobile web, and why is it something so different that it deserves whole books dedicated to it? Well, on one hand, it is nothing dramatic at all. The fundamental idea is still that you have a browser, a server, some standardized protocols and file formats passing between them, and a user who can view and traverse through content provided by site owners.
And you ’ ve now reached a point where, more or less, those protocols and fi les are written, produced, and interpreted in the same way on a desktop or laptop computer as they are on a mobile device. For markup, most mobile devices accept and handle some sort of XHTML or HTML5; for graphics, they can display PNG, GIF, or JPEG files with high color depth; for styling, at least simple forms of CSS should be understood and interpreted in some way; and, on contemporary devices, JavaScript is feasible for adding interactivity to a mobile website.
So far, so familiar. In terms of technology, you are more or less on familiar ground. You should be careful of one or two things: Flash and Silverlight, for example, are not recommended for widespread use on mobile handsets, because there are major swathes of devices that do not support either, so they should be used selectively at most.
But despite the fact that they build on the same standards, you do need to treat mobile browsers significantly differently from desktop ones. Some of the reasons for this are still technical in nature. A mobile network is not the same as a landline Internet connection, for example. There are considerations of throughput and latency — not to mention a possible cost to the subscriber — when a mobile device is accessing a website over a cellular network. Sensibly, a mobile website should be extremely considerate toward the requirements it makes on the network; large, unwieldy pages that are slow to display and render are clearly not well suited to the challenge.
Also, despite huge advances in processor power and graphics acceleration, most mobile browsers are running on hardware that is well below the specification of an average computer. Sites that put undue load on the CPU or even GPU of a mobile device are likely to be more sluggish than the same site on a desktop device. And even if the handset can provide a decent user experience for such a page, it probably comes at the expense of temperature or battery usage, something that is still at a premium in most handheld devices.
Finally, of course, a mobile device has a different form factor and size to a desktop computer. It certainly has a smaller screen, probably with a different default orientation, and may lack a physical keyboard and almost certainly lacks a mouse. Any website that makes desktop - based assumptions about a particular type of input device or screen size undoubtedly provides a suboptimal experience on a mobile device. For these reasons alone, it is worth thinking about the mobile web as a different medium than the desktop - centric Web that we all use.
But that ’ s not the whole story. Consider cinema and television, for example. There are certainly similarities between them: Both present visual information on screens, people sit and view them,
and both can display the same material in theory. But there is still no doubt that the two are treated as distinct media — even spawning entirely separate industries. Is there more to that distinction than simply the fact that the two have different sized screens?
Yes, of course. And the differences are context and user expectation. A cinema - goer is in a distinct state of mind: possibly out for the evening with friends or family, prepared to pay money for a very particular piece of visual entertainment, and amenable to being presented with a solid period of rich, visual storytelling — the movie he ’ s selected. The television occasionally gets used in this way, of course, but also services different sorts of expectation from its users: turning it on quickly to catch the news, short episodic programming, children ’ s ad - hoc entertainment, or even just as background noise. The way humans want to interact with the technology determines how content gets created for it.
So it is with the mobile web. Yes, many mobile devices can render the same websites as those designed for a desktop screen, but apart from the technical limitations of doing so, the ways in
which the two technologies actually get used can also be very different. A desktop user is sedentary, probably relatively comfortable, and quite probably using the Web for a lengthy session, either professionally or for leisure. A mobile user, snatching time to use her handheld browser, perhaps on the move, is more likely to have a shorter browsing session, has a focused goal in mind, and is far less likely to surf aimlessly about. The mobile user can easily be in a distinctly different state of mind and bringing an entirely different set of expectations to his web browsing experience.
Of course, there will be individual websites where exactly the same content, and exactly the same design, can be presented to multiple types of devices and users in different contexts. A site that comprises merely a simple collection of plain text documents, for example, probably doesn ’ t need to change significantly between mobile and desktop consumption (assuming the layout and typography adapts to different physical constraints).
But few sites on today ’ s Web are as static and immutable as that. Through the prevalence of content management systems, even the simplest personal website is database - driven, dynamically themed, administered online, and encouraging of reader feedback. Not only is it valuable to think about how different types of readers might want to consume the information on such a site, but it ’ s extremely easy to implement solutions that take account of the types of browsers they use, reformatting the page, promoting different sections of the site, resizing graphics for different screens, and so on.
From a site owner ’ s point of view, this is exciting: The mobile web is a distinct enough new medium to consider as a priority when designing and building a site, so it ’ s arguably a revolution . But from a practical point of view on the server, its implementation is merely an evolution : You can use today ’ s tools, today ’ s plug - ins, and your existing experience, and you can make use of the current content and functionality that you provide to the homogenous desktop user base and potentially get it into the hands of billions of mobile users.
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
And you ’ ve now reached a point where, more or less, those protocols and fi les are written, produced, and interpreted in the same way on a desktop or laptop computer as they are on a mobile device. For markup, most mobile devices accept and handle some sort of XHTML or HTML5; for graphics, they can display PNG, GIF, or JPEG files with high color depth; for styling, at least simple forms of CSS should be understood and interpreted in some way; and, on contemporary devices, JavaScript is feasible for adding interactivity to a mobile website.
So far, so familiar. In terms of technology, you are more or less on familiar ground. You should be careful of one or two things: Flash and Silverlight, for example, are not recommended for widespread use on mobile handsets, because there are major swathes of devices that do not support either, so they should be used selectively at most.
But despite the fact that they build on the same standards, you do need to treat mobile browsers significantly differently from desktop ones. Some of the reasons for this are still technical in nature. A mobile network is not the same as a landline Internet connection, for example. There are considerations of throughput and latency — not to mention a possible cost to the subscriber — when a mobile device is accessing a website over a cellular network. Sensibly, a mobile website should be extremely considerate toward the requirements it makes on the network; large, unwieldy pages that are slow to display and render are clearly not well suited to the challenge.
Also, despite huge advances in processor power and graphics acceleration, most mobile browsers are running on hardware that is well below the specification of an average computer. Sites that put undue load on the CPU or even GPU of a mobile device are likely to be more sluggish than the same site on a desktop device. And even if the handset can provide a decent user experience for such a page, it probably comes at the expense of temperature or battery usage, something that is still at a premium in most handheld devices.
Finally, of course, a mobile device has a different form factor and size to a desktop computer. It certainly has a smaller screen, probably with a different default orientation, and may lack a physical keyboard and almost certainly lacks a mouse. Any website that makes desktop - based assumptions about a particular type of input device or screen size undoubtedly provides a suboptimal experience on a mobile device. For these reasons alone, it is worth thinking about the mobile web as a different medium than the desktop - centric Web that we all use.
But that ’ s not the whole story. Consider cinema and television, for example. There are certainly similarities between them: Both present visual information on screens, people sit and view them,
and both can display the same material in theory. But there is still no doubt that the two are treated as distinct media — even spawning entirely separate industries. Is there more to that distinction than simply the fact that the two have different sized screens?
Yes, of course. And the differences are context and user expectation. A cinema - goer is in a distinct state of mind: possibly out for the evening with friends or family, prepared to pay money for a very particular piece of visual entertainment, and amenable to being presented with a solid period of rich, visual storytelling — the movie he ’ s selected. The television occasionally gets used in this way, of course, but also services different sorts of expectation from its users: turning it on quickly to catch the news, short episodic programming, children ’ s ad - hoc entertainment, or even just as background noise. The way humans want to interact with the technology determines how content gets created for it.
So it is with the mobile web. Yes, many mobile devices can render the same websites as those designed for a desktop screen, but apart from the technical limitations of doing so, the ways in
which the two technologies actually get used can also be very different. A desktop user is sedentary, probably relatively comfortable, and quite probably using the Web for a lengthy session, either professionally or for leisure. A mobile user, snatching time to use her handheld browser, perhaps on the move, is more likely to have a shorter browsing session, has a focused goal in mind, and is far less likely to surf aimlessly about. The mobile user can easily be in a distinctly different state of mind and bringing an entirely different set of expectations to his web browsing experience.
Of course, there will be individual websites where exactly the same content, and exactly the same design, can be presented to multiple types of devices and users in different contexts. A site that comprises merely a simple collection of plain text documents, for example, probably doesn ’ t need to change significantly between mobile and desktop consumption (assuming the layout and typography adapts to different physical constraints).
But few sites on today ’ s Web are as static and immutable as that. Through the prevalence of content management systems, even the simplest personal website is database - driven, dynamically themed, administered online, and encouraging of reader feedback. Not only is it valuable to think about how different types of readers might want to consume the information on such a site, but it ’ s extremely easy to implement solutions that take account of the types of browsers they use, reformatting the page, promoting different sections of the site, resizing graphics for different screens, and so on.
From a site owner ’ s point of view, this is exciting: The mobile web is a distinct enough new medium to consider as a priority when designing and building a site, so it ’ s arguably a revolution . But from a practical point of view on the server, its implementation is merely an evolution : You can use today ’ s tools, today ’ s plug - ins, and your existing experience, and you can make use of the current content and functionality that you provide to the homogenous desktop user base and potentially get it into the hands of billions of mobile users.
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
Dawn of the Modern Mobile Web
The years 2006 and 2007 were seminal in the development of the mobile web. For several years,
high - end mobile devices in Europe, Asia, and the United States had been gaining relatively high - resolution color screens and increasingly powerful processors. Together with a widespread rollout of third Generation (3G) network connectivity, sometimes with fl at rates of data usage, this now meant that many of the constraints of older devices and networks were now removed, and there was a decreasing need to rely on “ lite” pastiches of the Web, such as WAP and i - mode, to deliver information to handsets. Finally, there was a possibility that much of the regular web could be browsed, cost effectively, on high - end mobile devices.
A presage of this change was Nokia ’ s often overlooked decision to develop a port of the WebKit web browser to its Symbian operating system in 2005. (WebKit, the underlying engine of Apple ’ s recently released Safari browser, had been open - sourced by the company that year.)
Nokia ’ s first handsets to carry the resulting S60 Browser were extremely successful, if not entirely because of the browser alone. The fact that most browsers supported WiFi (for fast, free network connectivity) and that even the richest web content could be browsed quite capably (with the help of a full - screen zoom - in/out feature) meant that many developers saw a future in which the mobile device would become a viable first - class citizen of the Web, rather than one crippled by slow bandwidth and prohibitive Internet access.
Any lingering doubts that full mobile web access was just an esoteric dream were shattered in 2007, when Apple — a new entrant to the mobile handset business — launched its iPhone device.
Promoted as a combination of phone, music player, and Internet communicator, a large part of the iPhone ’ s attractiveness to consumers was its ability to render desktop websites with high fidelity, and pan and zoom through them elegantly using a multi - touch screen. The handset came bundled with unlimited data plans from most of its launch carriers.
When first launched, the iPhone did not allow third - party applications to run on it, and Apple encouraged those who wanted to create services for the device to do so through the use of the
web browser. Although the browser could display full web pages, developers quickly realized that users responded well to simple, efficient user - interfaces that mimicked the device ’ s built - in applications. Apple published guidelines for creating websites that adhered to iPhone - based user interface conventions, but which used fully fl edged web standards like HTML and CSS. As a result, thousands of web developers started creating iPhone - ready sites, targeted at these mobile users.
A wholehearted adoption of web technologies for mobile applications stalled somewhat with the
release of v2 of the iPhone operating system. With this release came the ability for developers to create native applications for the platform, together with rich access to device APIs (such as motion sensors, camera access, and geolocation) that the web browser did not provide. In the ensuing “ gold rush, ” thousands of developers fl ocked to developing these native applications — games in particular — that also held the opportunity for monetization through Apple ’ s newly launched App Store. Google ’ s Android platform was also launched in 2008, and while also sporting a very capable web browser, it encouraged developers to write native, rather than web - based, applications.
At the time of this writing, however, the mobile web is back in the ascendency. The irony is arguably that the native application concept has been a victim of its own success: users of many different handset platforms now expect to be given a native app experience, but the proliferation of high - end mobile operating systems means that the costs and effort involved in developing such apps is rapidly rising.
Developing web applications, on the other hand, offers the tempting opportunity to “ develop once, run multiply. ” Diversity between handset types and browsers means that there is still a strong need to create sites and designs that adapt to different browser platforms, screen sizes, and so on, but at least there is a chance to address a wide range of handsets, from the most - capable to the least - capable web - enabled device, with a common set of technologies and with a single development and deployment approach. Add to this the speed with which mobile browser technology is evolving, with which APIs are becoming richer, and with which the underlying standards are being developed, and it is no surprise that it is increasingly accepted that the Web looks set to be the dominant content delivery platform for the mobile generation.
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
high - end mobile devices in Europe, Asia, and the United States had been gaining relatively high - resolution color screens and increasingly powerful processors. Together with a widespread rollout of third Generation (3G) network connectivity, sometimes with fl at rates of data usage, this now meant that many of the constraints of older devices and networks were now removed, and there was a decreasing need to rely on “ lite” pastiches of the Web, such as WAP and i - mode, to deliver information to handsets. Finally, there was a possibility that much of the regular web could be browsed, cost effectively, on high - end mobile devices.
A presage of this change was Nokia ’ s often overlooked decision to develop a port of the WebKit web browser to its Symbian operating system in 2005. (WebKit, the underlying engine of Apple ’ s recently released Safari browser, had been open - sourced by the company that year.)
Nokia ’ s first handsets to carry the resulting S60 Browser were extremely successful, if not entirely because of the browser alone. The fact that most browsers supported WiFi (for fast, free network connectivity) and that even the richest web content could be browsed quite capably (with the help of a full - screen zoom - in/out feature) meant that many developers saw a future in which the mobile device would become a viable first - class citizen of the Web, rather than one crippled by slow bandwidth and prohibitive Internet access.
Any lingering doubts that full mobile web access was just an esoteric dream were shattered in 2007, when Apple — a new entrant to the mobile handset business — launched its iPhone device.
Promoted as a combination of phone, music player, and Internet communicator, a large part of the iPhone ’ s attractiveness to consumers was its ability to render desktop websites with high fidelity, and pan and zoom through them elegantly using a multi - touch screen. The handset came bundled with unlimited data plans from most of its launch carriers.
When first launched, the iPhone did not allow third - party applications to run on it, and Apple encouraged those who wanted to create services for the device to do so through the use of the
web browser. Although the browser could display full web pages, developers quickly realized that users responded well to simple, efficient user - interfaces that mimicked the device ’ s built - in applications. Apple published guidelines for creating websites that adhered to iPhone - based user interface conventions, but which used fully fl edged web standards like HTML and CSS. As a result, thousands of web developers started creating iPhone - ready sites, targeted at these mobile users.
A wholehearted adoption of web technologies for mobile applications stalled somewhat with the
release of v2 of the iPhone operating system. With this release came the ability for developers to create native applications for the platform, together with rich access to device APIs (such as motion sensors, camera access, and geolocation) that the web browser did not provide. In the ensuing “ gold rush, ” thousands of developers fl ocked to developing these native applications — games in particular — that also held the opportunity for monetization through Apple ’ s newly launched App Store. Google ’ s Android platform was also launched in 2008, and while also sporting a very capable web browser, it encouraged developers to write native, rather than web - based, applications.
At the time of this writing, however, the mobile web is back in the ascendency. The irony is arguably that the native application concept has been a victim of its own success: users of many different handset platforms now expect to be given a native app experience, but the proliferation of high - end mobile operating systems means that the costs and effort involved in developing such apps is rapidly rising.
Developing web applications, on the other hand, offers the tempting opportunity to “ develop once, run multiply. ” Diversity between handset types and browsers means that there is still a strong need to create sites and designs that adapt to different browser platforms, screen sizes, and so on, but at least there is a chance to address a wide range of handsets, from the most - capable to the least - capable web - enabled device, with a common set of technologies and with a single development and deployment approach. Add to this the speed with which mobile browser technology is evolving, with which APIs are becoming richer, and with which the underlying standards are being developed, and it is no surprise that it is increasingly accepted that the Web looks set to be the dominant content delivery platform for the mobile generation.
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
Wireless Access Protocol
The WAP Forum, formed in 1997, was a standards body dedicated to helping bring web - like access to simple handsets across low - bandwidth mobile networks (such as GSM and GPRS). The WAP standards that were produced, first as a reference v1.0 in 1998, and then as a deployable v1.1 in 1999, defined a whole stack of protocols to help deliver content efficiently across these networks.
Central to the WAP architecture was the role of the WAP gateway, which, like the UP.Link gateway, was responsible for taking content available on web servers hosted on the Internet and essentially compiling it into an efficient bytecode format that the browsers on the handset could efficiently handle and render. Because of this compilation process, content could not be written in arbitrary HTML; it had to be created in strict, well - formed WML — Wireless Markup Language.
WML was an XML - based language and was similar to HDML in that it relied on a card - based paradigm (as shown previously) and shared very few tags with HTML. Web developers who wanted to create sites for WAP handsets needed to craft entirely different markup and interfaces, even when the underlying content was shared with the regular web version of the site. (And unfortunately, the intolerance of many WAP gateways meant that web developers had to emit absolutely perfect XML syntax or risk cryptic errors on their users ’ screens.)
The earliest WAP devices included the iconic Nokia 7110 and the Ericsson R320, both released in 1999 and providing monochromatic access to simple WAP content. Both adhered well to the specifications, supporting simple images in cards, for example, and many pioneering developers
created sites for the devices. Nevertheless, the early hyperbole surrounding the potential of WAP
failed to meet user ’ s expectations: They were unable to “ surf the Internet ” on their mobile devices as they expected, finding that only those few sites that had crafted WML - based versions rendered on their screens.
Further, the increasing numbers of devices that shipped with WAP browsers over the following years brought a huge problem of diversity for site owners. Each browser could interpret certain sections of the WAP specifications differently, and the inconsistencies between implementations were frustrating for a web community that at the time was used to the ease of developing for a single web browser on the desktop environment.
For these, and many other reasons, WAP failed to gain the momentum that had been expected,
and it did not become the worldwide mobile web platform that many had hoped for. Network carriers, worried both about the unreliability of mobile sites on the Internet as a whole and keen to monetize data usage across their networks, often blocked mobile users from accessing arbitrary web addresses from their phones, preferring “ walled gardens ” of content from preferred partners, which often ended up as little more than directories of ringtones, desktop backgrounds, games, and other downloads.
WML underwent a number of revisions before the WAP Forum (which became part of a larger standards body, the Open Mobile Alliance) specified that WAP v2.0 should use a mobile subset of XHTML as its markup language. With that came the end of web developers ’ need to develop pages in an entirely unfamiliar markup and the start of a standards convergence between the modern desktop web (which was gradually, although not universally, adopting XHTML) and the mobile web of the future.
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
Central to the WAP architecture was the role of the WAP gateway, which, like the UP.Link gateway, was responsible for taking content available on web servers hosted on the Internet and essentially compiling it into an efficient bytecode format that the browsers on the handset could efficiently handle and render. Because of this compilation process, content could not be written in arbitrary HTML; it had to be created in strict, well - formed WML — Wireless Markup Language.
WML was an XML - based language and was similar to HDML in that it relied on a card - based paradigm (as shown previously) and shared very few tags with HTML. Web developers who wanted to create sites for WAP handsets needed to craft entirely different markup and interfaces, even when the underlying content was shared with the regular web version of the site. (And unfortunately, the intolerance of many WAP gateways meant that web developers had to emit absolutely perfect XML syntax or risk cryptic errors on their users ’ screens.)
The earliest WAP devices included the iconic Nokia 7110 and the Ericsson R320, both released in 1999 and providing monochromatic access to simple WAP content. Both adhered well to the specifications, supporting simple images in cards, for example, and many pioneering developers
created sites for the devices. Nevertheless, the early hyperbole surrounding the potential of WAP
failed to meet user ’ s expectations: They were unable to “ surf the Internet ” on their mobile devices as they expected, finding that only those few sites that had crafted WML - based versions rendered on their screens.
Further, the increasing numbers of devices that shipped with WAP browsers over the following years brought a huge problem of diversity for site owners. Each browser could interpret certain sections of the WAP specifications differently, and the inconsistencies between implementations were frustrating for a web community that at the time was used to the ease of developing for a single web browser on the desktop environment.
For these, and many other reasons, WAP failed to gain the momentum that had been expected,
and it did not become the worldwide mobile web platform that many had hoped for. Network carriers, worried both about the unreliability of mobile sites on the Internet as a whole and keen to monetize data usage across their networks, often blocked mobile users from accessing arbitrary web addresses from their phones, preferring “ walled gardens ” of content from preferred partners, which often ended up as little more than directories of ringtones, desktop backgrounds, games, and other downloads.
WML underwent a number of revisions before the WAP Forum (which became part of a larger standards body, the Open Mobile Alliance) specified that WAP v2.0 should use a mobile subset of XHTML as its markup language. With that came the end of web developers ’ need to develop pages in an entirely unfamiliar markup and the start of a standards convergence between the modern desktop web (which was gradually, although not universally, adopting XHTML) and the mobile web of the future.
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
i - mode in Japan
In February 1999, the Japanese network carrier NTT DoCoMo launched a service called “ i - mode ” as a feature that allowed mobile subscribers access to simple Web content on their mobile handsets. Rather than requiring a new markup language like HDML or WML, i - mode browsers were capable of rendering pages written in C - HTML, which was simply a subset of the HTML v3.2 language common at the time. Although publishers were encouraged to build special C - HTML sites specifically for i - mode usage, they used their existing HTML knowledge and tools, which meant there was a much smaller barrier to getting sites online. That factor resulted in a huge number of publishers doing so.
Many things contributed to i - mode (and similar rival offerings from other carriers) becoming hugely popular in Japan. One was the reliability and consistency of the browsers and the networks; another was the way in which DoCoMo provided billing mechanisms that allowed site owners to take payments from users for various commercial services. Some also suggest that the relative lack of PC - based Web access in Japan at the time also drove i - mode to success; for many consumers, their mobile device was the easiest and quickest way to access Web content at all, so i - mode adoption grew phenomenally (rising to 40 million users in a mere four years following its launch).
Whatever the reasons, i - mode and other Japanese mobile web platforms were held in high esteem by the mobile industry elsewhere in the world. Very quickly, their ubiquitous use throughout Japan became a blueprint for what a successful mobile web might look like, and several European and Asian carriers endeavored to replicate its success by using exactly the same technologies in their own networks several years later. (Notably, most of these were unsuccessful, suggesting that the i - mode technology itself was not the main factor of the Japanese network ’ s success.)
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
Many things contributed to i - mode (and similar rival offerings from other carriers) becoming hugely popular in Japan. One was the reliability and consistency of the browsers and the networks; another was the way in which DoCoMo provided billing mechanisms that allowed site owners to take payments from users for various commercial services. Some also suggest that the relative lack of PC - based Web access in Japan at the time also drove i - mode to success; for many consumers, their mobile device was the easiest and quickest way to access Web content at all, so i - mode adoption grew phenomenally (rising to 40 million users in a mere four years following its launch).
Whatever the reasons, i - mode and other Japanese mobile web platforms were held in high esteem by the mobile industry elsewhere in the world. Very quickly, their ubiquitous use throughout Japan became a blueprint for what a successful mobile web might look like, and several European and Asian carriers endeavored to replicate its success by using exactly the same technologies in their own networks several years later. (Notably, most of these were unsuccessful, suggesting that the i - mode technology itself was not the main factor of the Japanese network ’ s success.)
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
Early Mobile Web Technologies
One of the first companies to pioneer the concept of pull - based information services on a mobile device was Unwired Planet, based in California. Launched in 1996, the company produced a system called UP.Link, comprised of a software browser (UP.Browser) that ran on PDAs and mobile handsets, and a network - side gateway that would aid the browser in fetching and formatting sites written in the company ’ s proprietary markup language, HDML.
HDML was a card - based system for structuring content, and it bore little resemblance to HTML,
even in its simplest form. The basic principle was that the browser would retrieve a “ deck ” of such cards, allowing a user to look at a selection of related pages of information without the browser having to make additional requests to the server. The cards supported textual and basic image content, and allowed users to navigate through decks with simple links and soft - key anchors; it even initiated telephone calls.
In the U.S., AT & T ran a packet - switched data network called PocketNet, which was, at the time, one of the first consumer offerings to provide Web - like access on a mobile device. This service encouraged many early website owners to experiment with developing HDML - based sites for this niche U.S. market.
In 1997, Unwired Planet attempted, and failed, to get HDML adopted as a markup standard by the W3C, which would have been an important step in getting the technology widely used and used outside of the United States. However, in that year, Unwired Planet joined with Nokia and Ericsson (which had been developing Web - like markup languages of their own) to form the WAP Forum, a standards body that would go on to specify WAP and related standards. Much of the early structure of the resulting WML markup language came from the HDML syntax and concepts, and Unwired Planet adapted their infrastructure and browsers to support WAP, becoming a major worldwide vendor of browser and gateway products as a result.
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
HDML was a card - based system for structuring content, and it bore little resemblance to HTML,
even in its simplest form. The basic principle was that the browser would retrieve a “ deck ” of such cards, allowing a user to look at a selection of related pages of information without the browser having to make additional requests to the server. The cards supported textual and basic image content, and allowed users to navigate through decks with simple links and soft - key anchors; it even initiated telephone calls.
In the U.S., AT & T ran a packet - switched data network called PocketNet, which was, at the time, one of the first consumer offerings to provide Web - like access on a mobile device. This service encouraged many early website owners to experiment with developing HDML - based sites for this niche U.S. market.
In 1997, Unwired Planet attempted, and failed, to get HDML adopted as a markup standard by the W3C, which would have been an important step in getting the technology widely used and used outside of the United States. However, in that year, Unwired Planet joined with Nokia and Ericsson (which had been developing Web - like markup languages of their own) to form the WAP Forum, a standards body that would go on to specify WAP and related standards. Much of the early structure of the resulting WML markup language came from the HDML syntax and concepts, and Unwired Planet adapted their infrastructure and browsers to support WAP, becoming a major worldwide vendor of browser and gateway products as a result.
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
THE INEVITABILITY OF A MOBILE WEB
Your grandparents would probably recognize it as an archetypal scene from a science fiction book: Your protagonist, somewhere in the universe, pulls out a small handheld device, taps on it, and speaks. On the other side of the planet or spaceship upon which the action takes place, others receive the call, listen to the message, and begin to converse. It was not very long ago that wireless communication was the ultimate in futuristic high technology. As recently as 30 years ago, most people ’ s usage of telephones was relatively rare, costly, and short - distance. More importantly, it was utterly constrained by copper; you couldn’t make a call unless you were within a few meters of the handset. Only 15 years before that, most national and all international calls required an operator to patch calls through huge switchboard, cables and all.
In the late 1980s and 1990s, this started to change dramatically. Developments in radio and cellular technologies, coupled with the miniaturization and cheapening of computing hardware, enabled new possibilities: networks in which people could carry their telephone devices with them (or barely carry them, in the case of some of the early suitcase - sized models!), and, assuming they had sufficient radio coverage, place and receive calls while on the move.
Initially relying on analog technologies, and then through the creation and standardization of subsequent generations of digital technologies, these devices rapidly grew in number and fell in cost. At the same time, the cellular networks required to connect them grew in size, coverage, and interconnectedness. The cell phone became commonplace, even ubiquitous, and before you knew it, the constraints placed on where and when you could talk to friends and colleagues over the phone had been lifted.
Equipped with their miniature keyboards and screens, it was not long before other ways in which these small devices could be used started to emerge. The digital technologies used to transmit and receive voice were also perfectly capable of doing so for small amounts of data. Almost unintentionally, the GSM standard, for example, allowed users to send and receive short messages of 140 characters in length with their devices. By 2000, billions of such messages were being sent worldwide. Clearly the mobile device had the potential to be more than just a way to talk to others: It could be used as a device capable of sending and receiving data from other handsets, or indeed, central services.
The 1990s also saw the birth of the Web — a way in which computers could connect to the vast,
interconnected Internet and access pages of information residing on servers elsewhere, worldwide. Again, this had been an evolution from more primitive and simple technologies, but the Web burgeoned, thanks to factors such as the ease with which users could use browsers to navigate through content, the array of tools that made it easy for authors to create and publish content, and again, the decreasing cost and increasing power of computing hardware.
Buoyed by a dream of having the world ’ s knowledge and information formulated in an open way that humans could access it in dynamic and compelling ways, not to mention the prospects of being able to promote businesses and run commerce across the medium, the Web went from strength to strength, until by the end of the 1990s, it too was a powerful and familiar concept — at least in the developed world. With the benefit of hindsight, and noticing that two complementary concepts — the mobile phone and the Web — developed so significantly during the 1990s, it seems inevitable that at some point the telecoms and web industries would consider what it might mean to combine the two platforms.
For mobile networks and phone manufacturers, it meant the attraction of untethering people from their computers in the same way that they had been from their home telephones. For web and
software companies, reaching beyond the PC meant the opportunity to add hundreds of millions of new users to the Web. And for users, the idea of being able to access the vast array of information, content, and services — through their personal mobile device — would be the exciting realization of yet another chapter from science fiction. The idea, at least, of the mobile web was born.
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
In the late 1980s and 1990s, this started to change dramatically. Developments in radio and cellular technologies, coupled with the miniaturization and cheapening of computing hardware, enabled new possibilities: networks in which people could carry their telephone devices with them (or barely carry them, in the case of some of the early suitcase - sized models!), and, assuming they had sufficient radio coverage, place and receive calls while on the move.
Initially relying on analog technologies, and then through the creation and standardization of subsequent generations of digital technologies, these devices rapidly grew in number and fell in cost. At the same time, the cellular networks required to connect them grew in size, coverage, and interconnectedness. The cell phone became commonplace, even ubiquitous, and before you knew it, the constraints placed on where and when you could talk to friends and colleagues over the phone had been lifted.
Equipped with their miniature keyboards and screens, it was not long before other ways in which these small devices could be used started to emerge. The digital technologies used to transmit and receive voice were also perfectly capable of doing so for small amounts of data. Almost unintentionally, the GSM standard, for example, allowed users to send and receive short messages of 140 characters in length with their devices. By 2000, billions of such messages were being sent worldwide. Clearly the mobile device had the potential to be more than just a way to talk to others: It could be used as a device capable of sending and receiving data from other handsets, or indeed, central services.
The 1990s also saw the birth of the Web — a way in which computers could connect to the vast,
interconnected Internet and access pages of information residing on servers elsewhere, worldwide. Again, this had been an evolution from more primitive and simple technologies, but the Web burgeoned, thanks to factors such as the ease with which users could use browsers to navigate through content, the array of tools that made it easy for authors to create and publish content, and again, the decreasing cost and increasing power of computing hardware.
Buoyed by a dream of having the world ’ s knowledge and information formulated in an open way that humans could access it in dynamic and compelling ways, not to mention the prospects of being able to promote businesses and run commerce across the medium, the Web went from strength to strength, until by the end of the 1990s, it too was a powerful and familiar concept — at least in the developed world. With the benefit of hindsight, and noticing that two complementary concepts — the mobile phone and the Web — developed so significantly during the 1990s, it seems inevitable that at some point the telecoms and web industries would consider what it might mean to combine the two platforms.
For mobile networks and phone manufacturers, it meant the attraction of untethering people from their computers in the same way that they had been from their home telephones. For web and
software companies, reaching beyond the PC meant the opportunity to add hundreds of millions of new users to the Web. And for users, the idea of being able to access the vast array of information, content, and services — through their personal mobile device — would be the exciting realization of yet another chapter from science fiction. The idea, at least, of the mobile web was born.
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
The TPC
As noted earlier, the first attempts at standardizing a systems-level benchmark took place in the second half of the 1980s, with the introduction of the debit/credit benchmark, or TP1.
To mitigate deficiencies in the definition of this benchmark and to establish a rigorous basis for systems comparison, a group of computer systems vendors and DBMS vendors formed the Transaction Processing Council (TPC). The TPC aimed to both define a benchmark for transaction-processing systems and to specify rigorous publication rules for the results. Each TPC member is committed to obeying the rules, which require results to be accompanied by publication of a detailed report. Reports are subject to audit.
TPC then published a new benchmark to characterize decision support applications, and then, later, one for Web-based transactional applications. The history of TPC benchmarks can be summarized by the following list (benchmarks shown in bold were current at the beginning of 2002):
» TPC-A (1989): a simple transaction which does one update to a bank
account
» TPC-B (1990): the “database portion” of TPC-A
» TPC-C (1992): a benchmark involving multiple, complex transactions
» TPC-D (1995): decision support
» TPC-H (1999): decision support
» TPC-R (1999): decision support
» TPC-W (2000): Web-based transaction processing (e.g., electronic commerce, B2B, etc.)
The TPC benchmarks allow systems to be compared in two ways:
» Performance (for example, number of transactions per unit of time)
» Price/performance (for example, total cost of ownership over a threeyear period per transaction per minute)
The benchmark is not specified by source code, and so it is the responsibility of each TPC member who wishes to characterize a system to implement the benchmarks for those systems.
The TPC does not measure systems itself.
As far as the benchmarks are concerned, system cost comprises the cost of acquiring the system from the vendor (hardware and software) along with the costs of maintenance for three years. The transactions called for must be implemented properly, respecting the ACID properties of atomicity, coherence, insulation and durability.
Information on the activities and the standards issued by the TPC, as well as the published results of measurements, is available on their Web site at http:// www.tpc.org.
Source of Information : Elsevier Server Architectures
To mitigate deficiencies in the definition of this benchmark and to establish a rigorous basis for systems comparison, a group of computer systems vendors and DBMS vendors formed the Transaction Processing Council (TPC). The TPC aimed to both define a benchmark for transaction-processing systems and to specify rigorous publication rules for the results. Each TPC member is committed to obeying the rules, which require results to be accompanied by publication of a detailed report. Reports are subject to audit.
TPC then published a new benchmark to characterize decision support applications, and then, later, one for Web-based transactional applications. The history of TPC benchmarks can be summarized by the following list (benchmarks shown in bold were current at the beginning of 2002):
» TPC-A (1989): a simple transaction which does one update to a bank
account
» TPC-B (1990): the “database portion” of TPC-A
» TPC-C (1992): a benchmark involving multiple, complex transactions
» TPC-D (1995): decision support
» TPC-H (1999): decision support
» TPC-R (1999): decision support
» TPC-W (2000): Web-based transaction processing (e.g., electronic commerce, B2B, etc.)
The TPC benchmarks allow systems to be compared in two ways:
» Performance (for example, number of transactions per unit of time)
» Price/performance (for example, total cost of ownership over a threeyear period per transaction per minute)
The benchmark is not specified by source code, and so it is the responsibility of each TPC member who wishes to characterize a system to implement the benchmarks for those systems.
The TPC does not measure systems itself.
As far as the benchmarks are concerned, system cost comprises the cost of acquiring the system from the vendor (hardware and software) along with the costs of maintenance for three years. The transactions called for must be implemented properly, respecting the ACID properties of atomicity, coherence, insulation and durability.
Information on the activities and the standards issued by the TPC, as well as the published results of measurements, is available on their Web site at http:// www.tpc.org.
Source of Information : Elsevier Server Architectures
Numbering the Operations Master (OM) Roles
Most domain controller functionality in Windows Server 2000, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 was designed to be distributed, multimaster-based. This effectively eliminated the single point of failure that was present with Windows NT primary domain controllers (PDCs). However, five functions still require the use of a single server because their functionality makes it impossible to follow a distributed approach. These Operations Master (OM) roles (previously referred to as FSMO roles) are outlined as follows:
. Schema master—There is only one writable master copy of the AD DS schema in a single AD DS forest. It was deliberately designed this way to limit access to the schema and to minimize potential replication conflicts. There can be only one schema master in the entire AD DS forest.
. Domain naming master—The domain naming master is responsible for the addition of domains into the AD DS forest. This OM role must be placed on a global catalog server because it must have a record of all domains and objects to perform its function. There can be only one domain naming master in a forest.
. PDC emulator—This role used to exist to emulate the legacy Windows NT 4.0 primary domain controller (PDC) for down-level clients. With Windows Server 2008 R2, the PDC emulator still performs certain roles, such as acting as the primary time sync server for the domain. There is one PDC emulator FSMO role per AD DS domain.
. RID master—All objects within AD DS that can be assigned permissions are uniquely identified through the use of a security identifier (SID). Each SID is composed of a domain SID, which is the same for each object in a single domain, and a relative identifier (RID), which is unique for each object within that domain. When assigning SIDs, a domain controller must be able to assign a corresponding RID from a pool that it obtains from the RID master. When that pool is exhausted, it requests another pool from the RID master. If the RID master is down, you might not be able to create new objects in your domain if a specific domain controller runs out of its allocated pool of RIDs. There is one RID master per AD DS domain.
. Infrastructure master—The infrastructure master manages references to domain objects not within its own domain. In other words, a DC in one domain contains a list of all objects within its own domain, plus a list of references to other objects in other domains in the forest. If a referenced object changes, the infrastructure master handles this change. Because it deals with only referenced objects and not copies of the object itself, the infrastructure master must not reside on a global catalog server in multiple domain environments. The only exceptions to this are if every domain controller in your domain is a global catalog server or if you are in a single-domain environment. In the first case, there is no need to reference objects in other domains because full copies are available. In the second case, the infrastructure master role is not utilized because all copies of objects are local to the domain.
Transfer of an OM role to another domain controller can be performed as part of regular maintenance, or in the case of a disaster recovery situation where an OM server is brought offline, the OM can be seized to be brought back online. This is true for conditions where the schema master, domain naming master, PDC emulator, infrastructure master, or RID master either needs to be moved to another system (transfer) or has gone down and no backup is available (seized). The transfer and seizure of an OM role is done through the use of a command-line tool called ntdsutil, shown in Figure 4.4. Keep in mind that you should use this utility only in emergency situations and should never bring the old OM server that has had its role seized back online into the domain at risk of some serious system conflicts.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
. Schema master—There is only one writable master copy of the AD DS schema in a single AD DS forest. It was deliberately designed this way to limit access to the schema and to minimize potential replication conflicts. There can be only one schema master in the entire AD DS forest.
. Domain naming master—The domain naming master is responsible for the addition of domains into the AD DS forest. This OM role must be placed on a global catalog server because it must have a record of all domains and objects to perform its function. There can be only one domain naming master in a forest.
. PDC emulator—This role used to exist to emulate the legacy Windows NT 4.0 primary domain controller (PDC) for down-level clients. With Windows Server 2008 R2, the PDC emulator still performs certain roles, such as acting as the primary time sync server for the domain. There is one PDC emulator FSMO role per AD DS domain.
. RID master—All objects within AD DS that can be assigned permissions are uniquely identified through the use of a security identifier (SID). Each SID is composed of a domain SID, which is the same for each object in a single domain, and a relative identifier (RID), which is unique for each object within that domain. When assigning SIDs, a domain controller must be able to assign a corresponding RID from a pool that it obtains from the RID master. When that pool is exhausted, it requests another pool from the RID master. If the RID master is down, you might not be able to create new objects in your domain if a specific domain controller runs out of its allocated pool of RIDs. There is one RID master per AD DS domain.
. Infrastructure master—The infrastructure master manages references to domain objects not within its own domain. In other words, a DC in one domain contains a list of all objects within its own domain, plus a list of references to other objects in other domains in the forest. If a referenced object changes, the infrastructure master handles this change. Because it deals with only referenced objects and not copies of the object itself, the infrastructure master must not reside on a global catalog server in multiple domain environments. The only exceptions to this are if every domain controller in your domain is a global catalog server or if you are in a single-domain environment. In the first case, there is no need to reference objects in other domains because full copies are available. In the second case, the infrastructure master role is not utilized because all copies of objects are local to the domain.
Transfer of an OM role to another domain controller can be performed as part of regular maintenance, or in the case of a disaster recovery situation where an OM server is brought offline, the OM can be seized to be brought back online. This is true for conditions where the schema master, domain naming master, PDC emulator, infrastructure master, or RID master either needs to be moved to another system (transfer) or has gone down and no backup is available (seized). The transfer and seizure of an OM role is done through the use of a command-line tool called ntdsutil, shown in Figure 4.4. Keep in mind that you should use this utility only in emergency situations and should never bring the old OM server that has had its role seized back online into the domain at risk of some serious system conflicts.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
Subscribe to:
Posts (Atom)
Cloud storage is for blocks too, not just files
One of the misconceptions about cloud storage is that it is only useful for storing files. This assumption comes from the popularity of file...
-
Many of the virus, adware, security, and crash problems with Windows occu when someone installs a driver of dubious origin. The driver suppo...
-
The Berkeley motes are a family of embedded sensor nodes sharing roughly the same architecture. Let us take the MICA mote as an example. T...
-
To facilitate the development of network traffic filtering products, Microsoft created the Windows Filtering Platform (WFP). It is available...