You can almost hear them now — those marketing guys in the Microsoft corner offices — gotta beat the competition…no…gotta squash the competition…How can we do it? Better product? No…cheaper prices…yeah! At least that’s how we think it went when Microsoft was laying out it’s strategy for the release of Microsoft Dynamics Online.
Cops doing computer forensic work already have a ton of tools to choose from, but Microsoft is doing its part to help out as well — the company just revealed that it’s been distributing a special thumb drive to cops in 15 countries to help them identify and extract information from suspects’ computers. The drive, called COFEE for Computer Online Forensic Evidence Extractor, is in use by more than 2,000 officers, including some in the States, and Microsoft is giving it away for free, saying that its doing it not for profit but to “help make ensure the Internet stays safe.” COFEE contains more than 150 commands that can be used to collect information, decrypt passwords, and poke through network activity, which helps alleviate the problem of having to remove and transport a suspect’s computer for evidence purposes — officers can just plug in the drive. There’s no word on when Microsoft will start widely distributing the drives, but we’d assume it’ll be soon.
Blu-ray Disc is an optical disc storage media format used for high-definition video and data storage having the same dimensions as a standard DVD or CD. The blue-violet laser is used to read and write this type of disc, hence the name. Blue laser rays of 405 nanometer is used for Blu-ray Disc, while red laser rays of 650nm are used DVD format. Because of this, a dual layer Blu-ray Disc can store 50 GB, almost six times the capacity of a dual-layer DVD.
Blu-ray was developed by the Blu-ray Disc Association, a group of companies representing consumer electronics, computer hardware, and motion picture production. Currently more than 450 Blu-ray Disc titles have been released in the United States, and more than 250 in Japan. The Blu-ray format was promoted by Sony.
WiMAX stands for Worldwide Interoperability for Microwave Access. It is a telecommunications technology providing wireless data over long distances in a variety of ways, from point-to-point links to full mobile cellular type access. It is based on the WirelessMAN (IEEE 802.16) standard.
WiMAX is a highly scalable, long-range system, covering many kilometers using licensed spectrum to deliver a point-to-point connection to the Internet from an ISP to an end user. WiMAX can be used to provide a wireless alternative to cable and DSL for broadband access, and to provide high-speed data and telecommunications services. WiMAX can also be used to Connect many Wi-Fi hotspots with each other and also to other parts of the Internet.
When using WiMAX device with directional antennas, speeds of 10 Mbit/s at 10 km distance is possible, while for WiMAX devices with omni-directional antennas only 10 Mbit/s over 2 km is possible. There is no uniform global licensed spectrum for WiMAX, although three licensed spectrum profiles are being used generally – 2.3 GHz, 2.5 GHz and 3.5 GHz [wiki]
With WiMAX enabled handsets and laptops coming into the market, people could connect to the fast broadband internet from anywhere, without having to depend on the slow rate mobile network data transfer. You can work on broadband, call friends and colleagues and watch real-time TV from the top of a forest hill station many kilometers away from the access point – without compromising on quality, speed or screen size!
WiMAX could connect remote Indian villages to the Internet using broadband. This would avoid hassles in cabling through the forests and other difficult terrain only to reach a few people in remote places. Maintaining such system would also be easy. WiMAX could provide Internet access, voice and IPTV to those areas.
Comparison with Wi-Fi
Simply put, if WiMAX provides services analogous to a cellphone, Wi-Fi is more analogous to a cordless phone.
Wi-Fi is a shorter range system, typically hundreds of meters, typically used by an end user to access their own network. Wi-Fi is low cost and is generally used to provide Internet access within a single room or building. For example, many coffee shops, hotels, railway stations and bus stations contain Wi-Fi access points providing access to the Internet for customers.
Wireless Routers which incorporate a DSL-modem or a cable-modem and a Wi-Fi access point, often set up in homes to provide Internet-access and inter-networking to all devices connected (wirelessly or by cable) to them. One can also connect Wi-Fi devices in ad-hoc mode for client-to-client connections without a router. Wi-Fi allows LANs to be deployed without cabling for client devices, typically reducing the costs of network deployment and expansion. Wireless network adapters are also built into most modern laptops.
Sabeer Bhatia, founder of Hotmail.com, has announced the launch of SabSeBolo.com, the country’s first free, reservation-less audio conferencing facility.
To sign-up for the service, you need to log on to SabSebolo.com and enter your email id and password. In return, you’re given a permanent conference id and a pin. To start conferencing, you need to dial +91-22-3980 4444, enter the conference id and pin. You can also change your pin anytime.
At the launch, Sabeer Bhatia said that with Hotmail, he was able to provide free email ids to all Internet users. But that with SabSeBolo.com, he plans to do the same in the audio conferencing space initially in India and then in the world.
Bhatia said today, the youth as a group make up the most prolific telecom users, especially in SMS service. Given that SabSeBolo.com is a free service where you can conference with tens of your friends, it will definitely emerge as a new youth hangout.
SabSeBolo.com has wide application for individual and corporate communications. With the help of SabSeBolo.com, organizations can schedule conference calls with their team members at specified times. Individuals can plan events, get-togethers, etc. Friends and family who’re living apart can touch base with each other. Besides, SMEs and corporates can get private conferencing numbers if required.
Essentially a paid service without advertisements, SabSeBolo.com can also record conference calls to keep track of discussions and decisions taken as a paid service.
Yogesh Patel, co-founder of SabSeBolo.com, said a whole suite of related services such as free online conferencing scheduler, conference manager, dial-out service, voice broadcast, voice telecast, etc are scheduled to launch soon under SabSeBolo.com.
Windows Communication Foundation (WCF) is a distributed communication technology that ships as part of the .NET Framework 3.0. This article concentrates on comparing the performance of WCF with existing .NET distributed communication technologies. A prerequisite for this article is sufficient understanding of WCF. For an architectural overview of WCF please read “Windows Communication Foundation Architecture Overview” and to learn how to build services using WCF standard bindings please read “Introduction to Building Windows Communication Foundation Services” at http://msdn.microsoft.com/en-us/library/.
The goal of this article is to provide performance comparisons between WCF and other existing .NET distributed communication technologies. These technologies are:
The scenarios and data presented in this article quantify the underlying cost of the different technologies. This data is useful in understanding the relation between these technologies and can be helpful in planning migrations between the technologies. However, care should be taken in the conclusions drawn from the data presented in this article. The limiting performance factor in a well-designed Service Oriented Architecture (SOA) solution is most likely the service implementation itself and not the cost of the underlying communication technology. One must measure each application to determine the performance characteristics of that application. Note that this article does not address performance best practices when using WCF. Rather, it endeavors to provide sufficient information to enable you to make informed performance decisions when you are using an existing .NET distributed communication technologies as a basis.
All data presented in this article was collected using the same hardware configuration: four 2-way client systems were used to drive a server that was configured as a Uni or Quad processor. Two 2 GB cards were employed to guarantee that the network was not the bottleneck for any of the scenarios. See Figure 14 for details of the topology employed.
The number of client processes used on the client systems was sufficient to ensure that the CPU on the server was completely saturated. The data collected and presented reflects the average of the multiple convergent runs and care was taken to make sure all data was highly repeatable and sustainable.
All the comparisons in article are throughput comparisons and as such higher the value achieved, the better it is. In all the graphs, the higher bars reflect better performance.
This article focuses on the server throughput of the .NET distributed communication technologies. This is defined as the number of operations for each second that these technologies can sustain. An operation is a request and reply message with little processing done by the service. As mentioned in the introduction, but reiterated here as it is critically important, it is expected that the business logic will dominate the cost of a service in a well constructed SOA solution. By leaving out business logic processing at the service, only the cost of the messaging infrastructure is measured.
The message payloads used are different based on the comparison scenario and are explained for each comparative technology.
In this section the performance of ASP.NET Web services is compared with the performance of WCF. The scenario is request/reply between the client and the service. This is the typical message exchange pattern for both technologies. The request message in this scenario is required to send an integer. The reply message is comprised of an array of 1, 10 or 100 objects, each object being approximately 256 bytes long. The WCF object is an instance of a strongly typed data contract.
The signature of the function used to generate the message payload (objects) at the service is described in the following:
This section compares the performance of ASMX and WCF while they are hosted in IIS 6.0. In both cases, no security is used. The WCF binding used is the BasicHttpBinding. This standard binding uses HTTP as the transport protocol. The Basic Profile specification can be found at http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html. ASP.NET 2.0, part of the .NET Framework 2.0, provides CLR attributes to ensure conformance to the Basic Profile. For WCF the BasicHttpBinding provides the same level of guarantees.
As shown in Figure 1, WCF has improved performance over ASMX. Three different operation signatures (payloads) are shown in the graph. In each case an integer is passed from the client to the server and an array of objects (1, 10 or 100) is passed back to the client. WCF outperforms ASMX by 27%, 31% and 48% for 1, 10 and 100 objects in a message, respectively.
The graph in Figure 2 shows the throughput comparison of WCF and ASMX for the same scenario as Figure 1 but running on a quad processor. The throughput performance of WCF is better than ASMX by 19%, 21% and 36% for 1, 10 and 100 objects in a message, respectively. Note that the software used was not modified between the two configurations and a single service was exposed on the server. Comparing the data in the preceding two charts, the inherent scalability of the technologies can be noticed.
.gif)
Figure 1
.gif)
Figure 2
In this section, the performance of WCF is compared with the performance of ASMX with both operating over HTTPS. WCF uses the BasicHttpBinding for this scenario. Figure 3 shows the performance of WCF is better than ASMX when using transport level security. WCF outperforms ASMX by 16%, 18% and 26% for 1, 10 and 100 objects in a message respectively.
Figure 4 shows that the performance of WCF is better than ASMX by 5%, 12% and 13% for 1, 10 and 100 objects in a message respectively for a quad processor scenario.
.gif)
Figure 3
.gif)
Figure 4
In this section, the throughput of WCF is compared with the throughput of Web Services Enhancements. The comparison in this case is with WSE 2.0 but it should be noted that the performance of WSE 2.0 and 3.0 are similar for this payload. The method signatures and payload used for this scenario are identical to that employed in the ASMX scenarios (shown in Section 3.1).
In this section, message level security using X. 509 certificates as the security credential is used. The WSHttpBinding is used in WCF, which implements the WS-Security 1.1 specification. The transport protocol used is HTTP and the message exchange pattern remains request/reply.
Figure 5 shows WCF is much more efficient than WSE. The throughput of WCF is nearly 4 times better than WSE. The main reason for this is that WSE uses the System.Xml.XmlDocument class to do message level parsing, thereby loading the full message into memory at once, while WCF uses a streaming System.Xml.XmlReader class that improves the performance significantly.
Figure 6 compares the throughput of WCF and WSE 2.0 for quad processors. These results are similar to the performance gain achieved by WCF over WSE for single processor scenario. WCF is nearly 4 times faster than WSE with full message security.
.gif)
Figure 5
Figure 5 also illustrates the performance of another mechanism for securing messages in WCF: transport security with message credentials. This configuration combines transport-level security (HTTPS) and message-level credentials (for example, credentials in the SOAP message). To deploy this, WCF (Message Credentials) workload is using the BasicHttpBinding. The chart shows that the single processor scenario performance of WCF (Message Credentials) is better than WCF with WS Security by 129%, 166% and 277% for 1, 10 and 100 messages, respectively. The corresponding numbers for the quad processor scenario for WCF (Message Credentials) are even better and show an improvement of 126%, 156% and 248% for 1, 10 and 100 messages, respectively, over WCF (Message Credentials) for the uni processor scenario.
As can be seen from the chart, transport security with message credentials provides improved performance while still allowing rich message-level credentials. The message-level credentials include timestamp processing, canonicalization and signature processing. The message protection (signature, encryption, replay detection and other protection mechanisms) are still done at the transport byte stream level, below the individual message boundaries. There is a WS-Security header, but that only contains a timestamp, a security token and signature using that security token over the timestamp. Whereas, in the case where WCF uses full WS-Security, the message protection is done as a message-level transformation with signing and encryption done over the XML fragments for the headers and body. Also, the WS-Security header contains all the required security metadata as XML constructs. This extra XML-aware security processing and the larger size of the security header account for the performance difference. You have to consider the tradeoff between performance and security features available for the specific application that you might want to use this WCF setting in.
.gif)
Figure 6
In this section, the throughput of Enterprise Services (ES) is compared with WCF using two different service operation signatures and payloads. These are referred to as primitive and order messages. The primitive message is of a primitive type and this allows ES to execute its fast serialization path. The order message is a typical scenario that imitates a book order online and is approximately 512 bytes. The request/reply message exchange pattern is used for these comparisons.
The signature of the primitive payload is as follows:
Here the service just returns a string “successful” or “failure”.
For the order message the following code service is used:
static public ProductInfo CreateProductInfo(int count)
{
ProductInfo productInfo = new ProductInfo();
productInfo.TotalResults = count.ToString();
productInfo.TotalPages = “1″;
productInfo.ListName = “Books”;
productInfo.Details = new Details[count];
for (int x = 0; x < count; x++)
{
productInfo.Details[x] = GetDetail();
}
return productInfo;
}
static Details GetDetail()
{
Details details = new Details();
details.Url =
“http://www.abcd.com/exec/obidos/ASIN/043935806X/qid=1093918995/sr=k
a-1/ref=pd_ka_1/103-9470301-1623821″;
details.Asin = “043935806X”;
details.ProductName = “Any Book Available”;
details.Catalog = “Books”;
details.ReleaseDate = “07/01/2003″;
details.Manufacturer = “Scholastic”;
details.Distributor = “Scholastic”;
details.ImageUrlSmall =
“http://images.abcd.com/images/P/043935806X.01._PE60_PI_SZZZZZZZ_.jpg”;
details.ImageUrlMedium =
“http://images.abcd.com/images/P/043935806X.01._PE60_PI_MZZZZZZZ_.jpg”;
details.ImageUrlLarge =
“http://images.abcd.com/images/P/043935806X.01._PE60_PI_LMZZZZZZZ_.jpg”;
details.ListPrice = “29.99″;
details.OurPrice = “12.00″;
details.UsedPrice = “3.95″;
details.Isbn = “043935806X”;
details.MpaaRating = “”;
details.EsrbRating = “”;
details.Availability = “Usually ships within 24 hours”;
return details;
}
In these scenarios, the WCF service is self hosted and employs the NetTcpBinding.
Note You can use IIS 7.0, which is shipped with Windows Vista for hosting TCP services. In this case, the performance achieved is slightly less than the self-hosted case.
This section compares WCF with ES for two payloads previously discussed without any security. Figure 7 shows that sometimes ES is faster while other times WCF is faster. The performance of ES is better by 21% for the primitive message payload when the fast serializer can be used (possibly on a handful of primitive types like integers) but WCF outperforms it by 149% for order message payload.
Figure 8 shows the same benchmark and payload comparison on a quad processor. As WCF scales better than ES, WCF is faster than ES by 7% for primitive message even though ES can utilize its fast serialization path. For the order message, WCF is faster than ES by 104%.
.gif)
Figure 7
.gif)
Figure 8
In this section, the performance of WCF and ES are compared for the same message loads as the previous section (Section 3.3.1) with security enabled. Specifically, transport-level SSL security is employed and ASP.NET Role principle is used for the authorization. Figure 9 shows that the performance of ES on a uni processor is faster than WCF by 24% for the primitive message type while for the order message type, WCF is faster than ES by 69%.
Figure 10 shows that for quad processor, ES is better than WCF by 16% for the primitive message type and for the order message type WCF is faster by 37%.
.gif)
Figure 9
.gif)
Figure 10
In the previous two sections (Sections 3.3.1 and 3.3.2), the work done by the service was doing little more than creating the objects that were returned to the client. In this section, the throughput of WCF is compared with .NET ES when the services that are implemented use a database transaction. Please note that the transaction used is not flowed but is created and utilized within the service. The purpose of this scenario is to demonstrate that any substantial service implementation dominates the cost of the infrastructure independent of the technology used to deploy it. Hence the comparison is done only for the single proc scenario and only for primitive message type.
In Figure 11, WCF performance is compared with the performance of .NET Enterprise Service for a primitive message payload. As expected, the throughput of this scenario is significantly lower than the previous scenario because transactions are being used. Also as expected, the performance of the two technologies is nearly identical with WCF having slightly better performance.
.gif)
Figure 11
This section compares the performance of WCF and .NET Remoting when communication is required across processes on the same machine. Three different sized payloads, each an array of bytes are used for this comparison. The following interface illustrates the service operation signature:
Copy Codepublic interface IRemoteObject { [OperationContract] byte [] GetRBytes(int NumBytes); }
The size of the message payload returned is determined by the “NumBytes” which for the data below is 128 bytes, 4k and 256k. The NetNamedPipeBinding is employed without any security for this scenario.
The cross-process named pipe is used as the transport protocol along with request/reply as the message exchange protocol. As seen in Figure 12, WCF outperforms .NET Remoting by 29% and 30% for message payloads of 128 bytes and 4k bytes, respectively. As the payload grows in size, the performance of the technologies converge so that for the 256k byte array the performance is nearly identical.
In Figure 13, the corresponding data for quad processors is shown. The throughput of WCF is better by 38%, 18% and 28% for message payloads of 128 bytes, 4k bytes and 256k bytes, respectively.
.gif)
Figure 12
.gif)
Figure 13
When migrating distributed applications written with ASP.NET Web Services, WSE, .NET Enterprise Services and .NET Remoting to WCF, the performance is at least comparable to the other existing Microsoft distributed communication technologies. In most cases, the performance is significantly better for WCF over the other existing technologies. Another important characteristic of WCF is that the throughput performance is inherently scalable from a uni processor to quad processor.
To summarize the results, WCF is 25%—50% faster than ASP.NET Web Services, and approximately 25% faster than .NET Remoting. Comparison with .NET Enterprise Service is load dependant, as in one case WCF is nearly 100% faster but in another scenario it is nearly 25% slower. For WSE 2.0/3.0 implementations, migrating them to WCF will obviously provide the most significant performance gains of almost 4x.
.gif)
Figure 14
Figure 14 shows the machine configuration used is a single server and four client machines connected over two 1 Gbps Ethernet network interface. The server is a quad processor AMD 64 2.2 GHz x86 machine running Windows Server 2003 SP1. Each of the client machines are dual processor AMD 64 2.2GHz x86 machines running the same operating system as the server. The system CPU utilization is maintained at nearly 100%. All the scenarios that required hosting were done using an Internet Information Services (IIS) 6.0 server. For the single processor scenarios, the server is booted as a single processor machine.
If you are looking to build a successful website, here are three basic rules.
1. Fast Speed
First rule is, a website should load faster. When a user comes to your home page, there should be no wait. You can provide this by having only limited code and HTML on the home page.
There are several ways to make sure site load faster. For example, do not use too much graphics and flashy stuff. Use text, HTML controls instead of images.
Avoid default flash or other graphics items. If you can’t survive without flashy presentations, give user an option to load it once your home page is loaded by adding an extra link or something.
If your site is a database driven site, do not load too much data on page load. If it is necessary to load data from a database, try to save common data in application state so page load is faster.
2. Limited but Most Relevant Contents
Limited contents means if a user comes to your home page, site should provide only contents that you need to grasp the reader but not overload him. You do not want to confuse your reader.
Your home page should make sure that user is not confused about your site functionality and services. The message should be clear and consise. Make sure to put most relevant content on the most visible area.
3. Easy Navigation
You do not want user to click 4 times to go to the content what user is looking for. Try to keep it to 1 or 2 clicks only. At max, you can go to 3 clicks. After 3 clicks, user would most likely to leave your website.
Microsoft Live Labs Volta helps developers who build distributed applications on the .NET platform, using the Microsoft development stack (programming languages, libraries, and Visual Studio). This version of Volta supports applications that run on the Microsoft CLR, a JavaScript-enabled browser, or a combination of the two.
First, this document introduces the Volta technology. Then, it covers two important Volta targets that developers are likely to build and deploy: applications and controls. Recipe-like descriptions for several common web-based scenarios follow. The document concludes with an overview of the libraries installed with Volta, and a summary of known issues and limitations.
In essence Volta is a recompiler. Volta works on MSIL rather than on a textual source language. Volta rewrites MSIL into any number of target languages, including, today JavaScript and MSIL itself. Rewriting, as a general technology, lets us delay permanent decisions about architecture, execution platform and browser until after our code is basically working. Furthermore, it frees us from having to express all these irreversible decisions in your source code. The result is a programming model that enables us to easily reshape a working application, and finally realizes the promise of one application running anywhere.
Volta effects recompilation through 3 general capabilities: refactoring, retargeting, and remodulating. Refactoring converts single-tier code into distributed, concurrent code as directed by user-supplied annotations. Retargeting converts MSIL code into code for other virtual machines. Remodulating tailors a single piece of code for multiple browsers. The next 3 sections explain in more detail.
The Volta programming model takes refactoring one step further. Volta applies transformations on our compiled code based on metadata, in particular, custom attributes prefixed on classes or methods that could run on a server tier. During development, all code runs in the client for ease of testing and debugging. Redistributing the code amongst client and server is merely a matter of moving custom attributes around and rebuilding. The Volta rewriter automatically creates and deploys the marshalling and security code necessary to execute the code on multiple tiers. The following diagram illustrates evolution of a Volta application from single-tier architecture to a distributed, multi-tiered architecture.
After refactoring, notice that the same application that used to run in one instance of the CLR is now running on two tiers. Volta dramatically extends the reach of the .NET platform to cover the cloud. We emphasize that the only differences at the source-code level are the presence and positions of custom attributes. Volta doesn’t eliminate the intellectual challenges of distributed computing. We must still formulate strategies for partitioning functionality and dealing with network latency and availability. Volta does, however, radically simplify the error-prone plumbing and re-plumbing of communication code.
Volta leverages the entire .NET platform, including most libraries and programming languages. We can write in our favorite .NET languages, use familiar .NET libraries and tools, and produce sophisticated distributed applications using only the “materials already in the room.” Without Volta we are exposed to too many inconsistent, special-purpose languages with kludges to help them interact in the cloud. For instance, typical methodologies for cloud programming involve combinations of ASP, PHP, Flash, XML, HTML, CSS, JavaScript, Perl or Ruby, C# or Java, SQL, and even more! Volta reduces the brittleness of distributed applications by lowering the sensitivity to idiosyncrasies of multiple languages and dialects.
Another important advantage of architecture refactoring is opening up brown-field scenarios. With minimal changes we can run existing .NET code in the cloud, greatly increasing the user base of code that may have been designed only for a single tier. Volta gives us a new dimension of software reuse. Traditionally, we would endeavor to reuse bits and pieces of source code in new scenarios. Volta lets us reuse binaries in new scenarios.
In summary, Volta confers flexibility in the architecture dimension through:
Without Volta, we must choose not only the architecture, but also the execution environment before we write code. For example, we often start with a WinForms application, confining us to client-side architecture and CLR execution.
We’ve already seen that Volta tier splitting lets us refactor the application so that part of it runs on the server. Volta retargeting lets us run MSIL code also in a JavaScript engine. Primary scenarios involve JavaScript in a browser running the client side of a distributed application. However Volta is not tethered to the browser and retargeted code runs in any JavaScript engine, such as the Jscript engine bundled with Internet Explorer.
Volta retargeting employs the technique of deep embedding, which preserves precise semantics of CLR objects, classes, methods, events, and so on, despite some rather deep impedance mismatches between the two platforms. For instance, MSIL is statically typed, whereas JavaScript is dynamically typed. Volta does all the hard work for us, though, and we are not restricted to a subset of .NET language features. Anything MSIL can do, including events, exceptions, casts, and generics, runs precisely correctly on alternative platforms. Volta’s semantic fidelity is orthogonal to tier-splitting, so, with some limitations, it’s possible to fire events and exceptions across tiers, as if they were on the same runtime instance.
Let your imagination be your guide. Retargeting is independent of refactoring and we can mix and match them as appropriate to our scenarios.
Let’s develop a simple scenario. Consider a typical web application, and focus attention on the component running in the browser. Without Volta, we write HTML, CSS, and JavaScript, targeting the browser’s execution environment, in addition to server code. With Volta, we have one programming model for both tiers, namely .NET. Volta retargets the browser component, writing the JavaScript for us from MSIL, hiding the impedance mismatch.
Retargeting is all the more important in the face of Ajax, which encourages ever more functionality in the browser for increased responsiveness and better user experiences.
In summary, Volta confers flexibility in the execution-platform dimension through:
Despite the standardization of DHTML, which includes JavaScript and DOM access, many subtle differences exist amongst popular browsers. The rise of Ajax has amplified the differences, and furthermore, has created a sense of urgency in the marketplace, hence a continuous flow of new features and capabilities that developers must chase. Consequently, without Volta, developers must write more and more browser-specific code, leaving them less time to focus on their applications.
Volta hides as many browser-specific differences as possible, but still allows developers to leverage the unique capabilities of particular browsers. Instead of targeting solely the intersection of browser capabilities, Volta targets the entire union, but makes the intersection browser-agnostic. This is browser remodulating. From the developer’s point of view Volta attenuates browser differences. But what about testing and debugging? Volta and the Visual-Studio integration supports debugging and testing of applications with full transparency. Visual Studio’s Solution Platform dropdown lets us choose the specific browser we want for a testing/debugging session. This allows us to see how each browser renders the HTML.
In this release Volta supports the Internet Explorer and Firefox browsers. We accommodate specific browsers through a combination of changes to the recompiler and libraries, plus Visual Studio integration for debugging.
In summary, Volta confers flexibility in the execution-platform dimension through:
That’s right folks. Windows Vienna is the new codename for Windows Blackcomb the successor to Windows Vista.
Not much is known about Blackcomb officially and Microsoft is not ready to talk about it yet. However, Microsoft’s blogging guru, Robert Scoble confirmed in a thread reply to a channel 9 video, “since this video was shot the codename for Blackcomb has indeed changed to Vienna. I haven’t gotten the story on this yet, though.”
While Windows Vista is intended to be a technologies-based release, with some UI changes (in the form of the Aero set of technologies and guidelines), Vienna is targeted directly at revolutionizing the way we interact with our home and office PCs.
For instance, the “Start” philosophy, introduced in Windows 95, may be completely replaced by a “new interface” which was said in 1999 to be scheduled for Blackcomb, before being moved to the Longhorn project, and then back to Blackcomb. The interface involved some ideas based upon truely 3D Windows and an intergration of what is now known as Sidebar.
The Explorer shell is expected to be replaced in its entirety, with features such as the taskbar being replaced by a new concept based on the last 10 years of research from Microsoft’s “Vibe” lab. Projects such as GroupBar and LayoutBar are expected to make an appearance, allowing users to more effectively manage and keep track of their applications and documents while in use, and a new way of launching applications is expected – among other ideas, Microsoft is investigating a pie menu-type circular interface, similar in function to Apple’s dock feature.
All features are speculation and rumour at this point. However, with Vista arriving so late (5 years after Windows XP) – will Vista sell to the masses just as many enterprise customers have moved to XP and many home users are comfortable with XP. Time will tell.
SocialVibe