Storage Networking , Part 1 eBook: A storage network is any network that's designed to transport block-level storage protocols. But understanding the ins and outs of networked storage takes you deep into several of protocols. This guide covers SANs, Fibre Channels, Disk Arrays, Fabric, and IP Storage.
»Storage Networking 2, Configuration and Planning eBook: Picking up where Part 1 left off, Part 2 of our look at storage networking examines configurations for SAN-attached servers and disk arrays, and also includes a look at the future of IP storage.
»Storage Management Costs in the Enterprise: A Comparison of Mid-Range Array Solutions Whitepaper:
Many factors contribute to the ownership cost for enterprise storage. These include (but are not limited to): physical capacity relative to physical space requirements, performance capacity for data transfer and system reaction time, software maintenance and updates, expandability and flexibility, and much more.
»Storage Is Changing Fast Be Ready or Be Left Behind PDF: The storage landscape is headed for dramatic change, thanks to new technologies like Fibre Channel over Ethernet (FCoE), pNFS, object-based storage and SAS that will affect everything from NAS and SANs to disk drives. Get the knowledge you need to make the most of your storage environment, now and in the future.
»HP StorageWorks EVA4400 Demo:
Dont settle for an expensive and complex array that lacks functionality. The HP StorageWorks EVA4400 delivers virtual storage with enterprise class functionality at an affordable price.
»
Most pages on the web don't comply with the W3C's HTML
specifications. In some cases this is because their authors
wanted to take advantage of proprietary extensions; but in
many other cases, the pages could easily have been made more
conformant without any problem. This article explains what the
issues are, and why you should and how you can, bring your
pages into compliance with the HTML standards.
The fundamental reason for HTML standards compliance
is to ensure that you use only those elements and structures that are
likely to be understood by the widest range of user agents.
It's like English - if I were to speak my parent's dialect
(East Anglian) most other English speakers would not understand
everything I say. Similarly, if you use proprietary dialects of HTML,
some user agents won't understand everything you write. There is
however, a
standard
for HTML which the browser makers say they
support, and
validation
points out the divergences in your HTML source.
By adhering to the standards you maximise the accessibility of your work
to the widest range of user agents, and therefore, users.
Some people take the view that checking their pages in the two major
browsers is validation enough. Close, but no cigar.. There are still
dialect variants even within a single make of browser, across the
different versions and platforms - let alone between the two. And why
neglect all the other user agents such as text-mode browsers, text to
speech synthesizers, search engine spiders and other robots, site
analysis tools, etc? Perhaps, because it's too much extra work? Maybe,
but most of the compliance errors I've seen are trivial to fix, e.g.
missing ALT attributes (not tags!) in IMG tags. Others might be harder
to understand and fix but practice overcomes this, and in the end your
"inner satisfaction" is in knowing that you've done a good professional
job that can be appreciated by all.
Sites often use a "browser sniffer" to detect which browser you're
using, and then serve you a page specifically optimized for your
browser. As the
WaSP says in their
mission statement
"Creating multiple versions of the same Web page because of
incompatibilities among browsers is wasteful and self-defeating
for Web developers and their clients. The alternative is to try to
resolve the incompatibilities by often complicated workarounds that
are costly for developers and their clients - at the cost of preventing
Web pages from being flexible enough to be used by emerging
television-based and PDA-based browsers."
HTML standards are designed to remain as backward-compatible as
possible while also attempting to be as forward-compatible as possible.
In particular, they are designed so that older conformant pages are not
too likely to break on newer browsers, and future conformant pages will
"gracefully degrade" on older browsers. Choosing to adhere to any
proprietary format, or none in particular, is very likely to cause a
site to look worse under older browsers, or future browsers, than if
the standards were followed. According to
W3C's
HTML 4.0
"Most people agree that HTML documents should work well across
different browsers and platforms. Achieving interoperability lowers
costs to content providers since they must develop only one version of a
document. If the effort is not made, there is much greater risk that the
Web will devolve into a proprietary world of incompatible formats,
ultimately reducing the Web's commercial potential for all participants.
Each version of HTML has attempted to reflect greater consensus among
industry players so that the investment made by content providers will
not be wasted and that their documents will not become unreadable in a
short period of time.
HTML has been developed with the vision that all manner of devices
should be able to use information on the Web: PCs with graphics displays
of varying resolution and color depths, cellular telephones, hand held
devices, devices for speech for output and input, computers with high or
low bandwidth, and so on."
The solution is for developers to adhere to the HTML standards, and for
the browser makers to support them fully before adding their
innovations. Let's examine the issues in a little more depth:-
"Standards":
At some point W3C apparently decided to relinquish any claims to be a
standards body, and to leave that function to other organisations such as
ISO. See for example
Information Technology -- Document Description and
Processing Languages -- HyperText Markup Language (HTML).
The issue is also a matter of semantics as well as history. If there is no
specification that can be strictly defined as an HTML 'standard' after v
2.0, there is nevertheless a strong need for some reference point more
up-to-date (with current practice) than v 2.0; and so common usage treats
the HTML 4.0 Recommendation as the ad-hoc standard until ISO or some other
acknowledged standards body rubber-stamps it..
