Advantages & Disadvantages of Selenium supported Programming Languages – A summary

             LANGUAGE NO                                                                        ADVANTAGES                                                DISADVANTAGES
                   JAVA 1 Java is distributed.Distributed computing involves several computers on a network working together. 1   java programs runs on a virtual machine.its run slowly compared to other programs
2 In java language compiler,interpreter and runtimes environment were each one developed with security mind 2    some problem in programs do not always correctly even if they  written correctly because a JVM may be written incorrectly.Diffuclt to write a program.
3 In java programming provides multimedia facilities that will enable programmer to develop multimedia application. 3  No separation of specification from implementation and no precondition and postcondition
4 Java Is architecture is platform independent.
                      C# 1 C# is safer to run. C# program is compiled into an intermediate language, the OS can always check it to see that no malicious code is about 1    C# is less flexible than C++.  C# depends greatly on .NET framework, anything that is not found in the .NET framework will be difficult to implement.
2 Cost of maintenance for C# is  much lower than that of C++.  This is a positive side effect of C# helping programmers to write program that is as bug free as possible. 2   Its doesn’t support multiple inhertaince.
3 C# implements the modern programming concept of Object Oriented Programming which enables the developer to produce secure data applications. 3    C# is slower to run.
4 C# supports effective and reusable components.
                  PYTHON 1 Python does not use any syntax rule instead of tabbing and spacing play an any important role in program flow. 1   Python is interpreted the runtime of the program is 1-5times slower than java or c,c++.
2 Python does not enforce a strict type on containers or variables. Developers can design a container to hold different types of data 2   Python is not best for memory intensive tasks.
3 A program written in python for one platform using only the standard libaries can easily ported to another operating system without need for recompling and repackaging. 3   Python is not great choice for high graphic 3d  game that takes up a lot of cpu.
4 Python is general purpose language.It’s ease of learning,protablity,dynamic typing and integration with other languages. 4    Some other drawbacks are language translation,documentation,and use of modules.
                      RUBY 1 Ruby is a pure oop allows inhertaince,encapuslation,and polymorphism of objects. 1    Ruby is an interpreted language.The source code has to be interpreted at runtime that means it run slower than equivalent compiled application.
2 Ruby is also dynamic language.The methods and variable may added and redefined at runtime. 2   If some one uses your application will also be able to see source code. Its not secure.
3 Ruby also very high level language.That mean it can handle complex data structure,and  complex operation on them with relatively few instruction.
4 It has a smart grabage collector.and it is scripting language.It make easy to do scripting opeartion like examining system resource,using pipes,capture output and so on.
                 PERL 1 It s protablity.perl code that doesnot use system specific features ,can be run on any platform. 1    If you can’t easily create a binary image  from a Perl file. It’s not a serious problem on Unix, but it might be a problem on Windows.
2 Perl makes using composition for code reuse very straightforward. 2   Perl is that of function signatures or rather the lack of signatures. In most programming languages when you declare a function you also declare its signature, listing the names of the parameters and in some languages also their types. Perl doesn’t do this.
3 Its allow multiple inheritance and operator overloading. 3   In perl hard to build data structure
4 Perl provides some features that are required for large projects.That are modularization,object orinted technquies,arbitary data structures. 4   This makes it hard to read even well-written code of programmers who happen to use features you are less familiar with.
                   PHP 1 PHP is open source.It is developed  and maintained by a large group of PHP developers this will helps in creating a  support community, abundant extension library. 1   PHP has security problem. It is open source So all people can see the source code.
2 It is stable.since it is maintained by many number  developers, so when bugs are found,it can be quickly fixed. 2    Not suitable for large applications: Hard to maintain since it is not very modular.
3 You can connect to database easily using PHP since many websites are data or content driven  so we will use database frequently, this will largely reduce the development time of web apps. 3   Not good  to create desktop application.
4 It can be run on many platform. 4   PHP tends to execute more slowly than assembly, C, and other compiled languages

A Matter of Semantics: Structuring client-server communications with hypermedia messages

 Messages on the Web carry three levels of information: Structure Semantics, Protocol Semantics, and Application Semantics. No matter the implementation style, all three of these are needed for any successful communication between client and server. This threesome (S-P-A) forms the essentials of communication over distributed networks.

Most of the time, though, these levels are obscured or muddled at implementation time. For example, both Protocol Semantics (how we create valid network requests) and Application Semantics (domain names like users, customers, orders, etc) are often mixed together in conversation (“You POST new users to this URL”) and both of these are usually only defined in human-readable documentation and implemented in the source code of the client application itself. In other words, the protocol-level and application-level semantics are tightly coupled. An easy way to discover this is to see if you can take the same message format and implement your API using a protocol other than HTTP (e.g. WebSockets or FTP).  illustrated this “protocol-agnostic” design pattern back in 2010 (“A RESTful Hypermedia API in Three Easy Steps”).

But there is a way to keep these separate from each other and view each of these aspects in their own light. In doing so, you’ll strengthen the quality and value of your message design while increasing flexibility and choices.

Structure Semantics

Structure Semantics provides the set of rules regarding how to create a well-formed message. XML has rather simple structure semantics. JSON’s rules for well-formedness are a bit more vague but reachable since JSON.parse(…) turns out to be the ultimate arbiter of such things. Determining well-formedness of other, more complex media types (HTML, Atom, HAL, Collection+JSON) is tougher, but do-able even if external validators are not always available.

Building a successful web implementation that does not contain structure semantics is difficult—and that’s a good thing.

Protocol Semantics

Protocol Semantics is the set of rules regarding how to fashion valid requests and responses using one or more message protocols. HTTP, FTP, WebSockets, etc. are all message protocols. Most implementations for the Web use human-readable documentation to describe these semantics. For example, typical RPC-style implementations document URIs, associated request rules (HTTP methods and headers), and any possible body content.

Hypermedia-style implementations express the protocol semantics directly in the message (usually in the body, but sometimes in HTTP headers). The most common way this is done is to include rules for links and ‘forms’ that may appear in server responses (think HTML).

Registered media types don’t often include hypermedia controls. For example, CSV, XML, and JSON have no definitions for hypermedia expression within the message. However some media types such as HTML, Atom, HAL, Collection+JSON (and others), do include the predefined ability to express protocol-level information within the message sent from the server.

Application Semantics

Application Semantics govern the way in which application-specific information is shared between client and server. This includes names of domain data elements (users, customers, products, etc.) and specific actions within the domain (adding a user, calculating tax on purchases, etc.). Well-formed requests and responses are ones that contain valid expressions of these domain-specific concepts. There are very few registered media-type designs that contain this level of specificity and the ones that do contain it are usually aimed at an industry-wide domain (e.g. VoiceXML and Maze+XML).

There are some machine-readable examples of application semantics that can be used in conjunction with existing structurally semantic forms (XML, JSON, etc.). XSD, JSON-Schema, and other schema-based document types do a good job of expressing application-specific information. There are other examples such as WSDL for SOAP and its cousin WADL.

Most of the application-level semantics exist as stand-alone content with no standardized way to apply that information to a message. Some media type designs are better than others at supporting application-level semantics. HTML, for example, has several attributes (id, name, class, rel) with which you can apply application-level semantic information to a message.

Semantic Profiles

An alternative approach to application-level semantics is the use of a “Profile.” Tantek Celik has been championing this approach since 2003 with his XHTML Meta Data Profiles pattern for HTML. The “profile” link relation was recently registered with the IANA and there has been some renewed interest in this model. The POWDER spec uses the “describedby” link relation in a similar way, too.

The Profile pattern lets you outline the application semantics independent of the protocol and structure. You can collect up all the data points (userName, address, email, phone, etc.) and all the possible actions (addUser, editUser, approveUser) into a single place. The profile provides a clear, stand-alone description of the problem domain that can be kept up-to-date without mixing in protocol (HTTP, WS, etc.) or format (XML, Atom, HTML, etc.) details.

Even better, you can create a machine-readable version of this profile: one that can be referred to at run time by both client and server implementations. The Application-Level Semantic Profile (ALPS) format was designed for this purpose. This is an early attempt at a specification that supports profile descriptions that can be shared and applied to multiple media types (structures) and protocols. It’s too early to know if this kind of approach will become widely adopted, but I think it is worth pursuing.

Design Hallmarks

Designing a message format requires solving for all three levels (structure, protocol, and application). The simplest approach is to select an existing structural format (XML, JSON, etc.) and then use human-readable documentation to apply the other two (protocol and application). This requires added implementation coordination between client and server, but is quite common.

Selecting (or designing) media types that include protocol semantics and/or support applying application semantics directly within the message puts added responsibility on the message designer(s) and standardizes much more of the way client and servers interact. This can increase the likelihood that compatible implementations can be done at a distance (both in space and time) and that implementors (client and server developers) have an opportunity to safely evolve communications over time including adding new interactions to the domain-space without the need for prior coordination with the initial message designer.

These two aspects of the Web, support for distance and evolvability, are a hallmark of hypermedia-style designs.

What the new TLDs mean for brands and consumers

Domain changes afoot on the internet and what we can expect to see from this new online landscape in the coming months

In 2011, ICANN, The Internet Corporation for Assigned Names and Numbers (ICANN) the body that governs addresses on the internet, recently made the decision to allow brands and organisations to apply for and manage their own unique top-level domains (TLD). Businesses (and others) that submitted a successful application and met all of ICANN’s requirements are about to have their name featured on the right side of the dot in web addresses for the first time. In ICANN’s ‘dot Brand’ new world, you can expect to see domains such as .CHANEL or .NIKE alongside familiar domains such as .COM, .INFO and .ORG. In short, brands are no longer constrained to the left of the dot (as in ‘’), but can now have their own identity at the very top level (as in ‘’).

Dawn of a new domain

The internet’s makeover will begin to show up publicly later this year; that’s when we expect to see the first of hundreds of new domains that will be launched. ICANN received almost 2,000 applications – some for branded domains such as .HSBC, but also applications for generic terms like .FOOD and for geographic regions like .LONDON and .RIO.

The decision to expand the TLD system was made to introduce greater internet innovation and competition. One key innovation is to enable brands to free themselves from the need to market under irrelevant names like ‘.com’ or ‘Facebook’, and focus entirely on their own identity. Since domain names are now a critical component of a brand’s identity, ICANN’s gateway to TLD ownership represents a turning point in brand management on the internet. When the new domains launch later this year, we’ll certainly see revised marketing strategies from these brands, who will be keen to reap the advantages such domains offer, including a strengthened online identity, improved security and new possibilities for customer engagement.

However, dot Brands also present benefits to online consumers. In particular, these domains will inject greater confidence into the ecommerce space, an area that has been plagued with counterfeiting and other security issues. By ICANN mandate, all new TLDs must be DNSSEC enabled. This relatively security new technology helps ensure that consumers who type in an address with a dot Brand extension will arrive at the intended site, instead of a phishing or other counterfeit-type site. Especially for shoppers of luxury goods or pharmaceuticals, dot Brand addresses finally enable confidence that the goods are from a legitimate source. Furthermore, since each dot Brand is completely controlled by the brand owner such as Rolex, they can exercise total control over who is permitted to use a .ROLEX web address.

Another key innovation is the introduction of non-Roman scripts for top-level domains. This will enable Chinese character addresses, as well as addresses in Cyrillic, Korean, Japanese, Hindi and so on … thus opening up the internet to millions of new users.

Without the expansion of top level domains, many potential participants in the global internet may have continued to find themselves excluded. The multi-language internet is critical to bridging the digital divide, particularly when internet availability expands to non-English speaking areas. For global retailers and marketers, non-Roman script names present the opportunity to connect with the world’s growing markets in local languages like Arabic, Russian and Chinese. Amazon is one of the first to move into this space with its application for 家電 (Japanese script for “consumer electronics”) while L’Oréal has opted for 欧莱雅 (the Chinese transliteration of “L’Oréal”).

Dot foes?

Despite the benefits, the prospect of dot Brand top-level domains have generated controversy and disagreement. Some opponents disagree with businesses being allowed to apply for generic terms such as .BEAUTY, while religious and conservative groups object to domains such as .ISLAM or .SEXY. Others have voiced concerns about players like Amazon and Google reinforcing their dominant market positions and monopolising entire online categories as with the respective applications for .BOOKS and .SHOP.

However, these terms exist now at the second level in many existing domains (for example,, and have not caused any particular problems. Further, generic terms have been trademarked in various jurisdictions for decades. Given these facts, the opportunity to have them at the top level of a domain name seems to be a natural evolution.

Standing out in a dot Brand crowd

Although the initial application period closed last year, ICANN has said that the opportunity to own a TLD will come again in the future once the first batch of dot Brands are delegated and active. Even if you missed the first round, you can put other proactive measures in place to help ensure your brand is not overlooked in the new, branded online landscape.

First, businesses should ensure that its main website address is the central location for all digital assets. Diverting an online audience to other channels, whether it’s a Facebook page or Twitter handle, effectively reroutes them to another company and dilutes a business’s own online brand presence. While a social media presence is essential, every brand needs its own unique home that can be completely controlled by the company’s brand management and where customers cannot be tracked or otherwise exploited by a third party.

Additionally, with Forrester predicting that mobile commerce is set to quadruple to $31 billion in the next five years, preparing for the m-commerce boom is essential for competing in the new online environment. Consumers now expect a seamless online experience, regardless of the type of device used to access a business’s website. To that end, businesses must ensure that existing websites are optimised for mobile viewing.

While the success of the new TLDs is yet to be determined, one thing is for sure: the internet is continuing to grow and play an ever-larger role in our lives. Regardless of whether a business has applied for a dot Brand, the tide of change sweeping across the internet means businesses need to ensure their digital presence is in order in 2013 and beyond.