The Qworum Blog

We are at Cloud Expo Europe 2012

2012-01-16T12:16:00.001+01:00

We are pleased to announce that we will be attending Cloud Expo Europe, which starts on January 25th and ends on January 26th. Come and visit us at stand 825.

What HTML5 can't do

2011-11-12T00:37:00.001+01:00

Since the early days of the World Wide Web, new capabilities were being added to browsers in order to better support web applications. This effort was started by the Netscape team, notably with HTTP-based cookies and the Javascript language. Nowadays, that activity largely takes place under the HTML5 umbrella, where browser providers and standards bodies define new browser features.

An important need that these efforts do not address, however, is application modularity, and that's where Qworum comes in.

So, how can web applications leverage Qworum?

First, web developers can use Qworum for implementing more complex web applications with less effort.
Qworum is currently the only technology that enables modular web applications. Consider how important code re-use is for developer productivity, and how difficult it would be to develop even the simplest desktop application without readily available software libraries in the form of classes, functions, etc. Amazingly, this is the situation that web developers found themselves in before Qworum.

Let me add that Qworum is free when used internally by internet web applications (that is, when Qworum services are hosted on the same domain as the web application that calls them).

Second, web applications can be better integrated with each other using Qworum.
For example, internet websites can use Qworum for providing user authentication services (i.e. OpenID) or payment processing services (i.e. PayPal, Google Checkout) to other internet websites. Qworum greatly facilitates these types of scenarios.

Currently, internet websites can provide paid services to other internet sites and businesses. If you would like to provide free Qworum services to internet websites, and if the services will be widely used, contact us.

How browser providers are compensated by Qworum

2011-10-29T22:56:00.000+02:00

I have briefly mentioned our partner program in a previous post. In this post, I will delve into actual numbers, including revenue projections for various browser providers.

Our compensation program is structured in a way that rewards:

Senior partners (browser providers have an incentive to become our partners early on),
Partners with bigger browser market shares,
Partners with higher quality Qworum implementations.

A word on that last point:

The Qworum specification defines some features whose implementation is problematic in browser add-ons, due to the restrictive APIs that are available to them. We chose to make these features optional, so that an implementation can lack these features and still be valid.

In order to encourage our partners to implement those optional features, we have introduced the concept of implementation quality, which is an important factor in partner compensation.

Quarterly payments

Our partners are compensated on a quarterly basis, so that public companies can include their Qworum earnings in their results announcements.

Up to 20% of Qworum revenue allocated to partners

Up to 20% of our DRM revenue, and up to 20% of our Enterprise revenue goes to our partners. The revenue received by a given partner depends on their seniority coefficient (=0.75^(seniority-1)), their DRM and Enterprise market shares coefficient for the quarter (as measured by the percentage of requests received on user-agent.qworum.com), and the quality coefficient of the Qworum implementation in their latest browser at the moment of payment.

The implementation quality coefficient is currently determined as a sum of the weights of the following implemented features (these may change from quarter to quarter):

[weight: 0.50] Implement the Core 1.0 specification (mandatory for all partners),
[weight: 0.15] Prevent end-users from choosing target frames (1),
[weight: 0.12] Transform bad responses into faults (1, 2, 3),
[weight: 0.09] Clear tab history (1),
[weight: 0.06] Use application/xml for POSTs (1, 2),
[weight: 0.05] Send correct referrer headers (1),
[weight: 0.03] Prevent bookmarking (1).

Here is the percentage of Qworum revenue that would go to a particular browser provider depending on seniority (supposing perfect implementation quality, and DRM and Enterprise market shares equal to their current browser market share):

Mozilla (Firefox):

1: 4.3 %

2: 3.2 %

3: 2.4 %

4: 1.8 %

5: 1.4 %

Google (Chrome):

1: 2.4 %

2: 1.8 %

3: 1.3 %

4: 1.0 %

5: 0.8 %

Opera:

1: 0.4 %

2: 0.3 %

3: 0.2 %

4: 0.2 %

5: 0.1 %

Apple (Safari):

1: 1.4 %

2: 1.1 %

3: 0.8 %

4: 0.6 %

5: 0.5 %

Microsoft (Internet Explorer):

1: 11.0 %

2: 8.3 %

3: 6.2 %

4: 4.6 %

5: 3.5 %

Human languages have a tendency to be imprecise, so I am including here a ruby program that implements the compensation algorithm:

#! /usr/bin/env ruby

class QworumPartnerCompensation

def initialize

@PARTNER_SHARE = 0.20

end

# Calculates the percentage of DRM revenue that goes to a particular browser provider partner

def partner_drm_share partner_seniority=1, partner_drm_usage=1.0, partner_implementation_quality=1.0

@PARTNER_SHARE * seniority_adjustment(partner_seniority) * partner_drm_usage * partner_implementation_quality

end

# Calculates the percentage of Enterprise revenue that goes to a particular browser provider partner

def partner_enterprise_share partner_seniority=1, partner_enterprise_usage=1.0, partner_implementation_quality=1.0

@PARTNER_SHARE * seniority_adjustment(partner_seniority) * partner_enterprise_usage * partner_implementation_quality

end

def seniority_adjustment seniority=1

return 0.0 if seniority<1

0.75**(seniority-1)

end

exit 0 if __FILE__ != $0

q=QworumPartnerCompensation.new

puts "---------------------------------------------------"

puts "Partner revenue adjustment coefficient by seniority"

puts

(1..5).each do |n|

puts format "#{n}: %.3f ", q.seniority_adjustment(n)

end

puts

puts "---------------------------------------------------------------------------------------------"

puts "Total percentage of Qworum revenue that would be received by the 5 leading browser providers,"

puts "depending on partnering order"

puts "(hypothesis: browser DRM usage == browser Enterprise usage == current browser market share)"

puts

browser = []

browser << ['Mozilla (Firefox)', 0.2163]

browser << ['Google (Chrome)', 0.1194]

browser << ['Opera', 0.0214]

browser << ['Apple (Safari)', 0.0715]

browser << ['Microsoft (Internet Explorer)', 0.5511]

min=1.0

max=0.0

(0..(browser.size-1)).each do |n1|

(0..(browser.size-1)).each do |n2|

next if n2==n1

(0..(browser.size-1)).each do |n3|

next if n3==n2 or n3==n1

(0..(browser.size-1)).each do |n4|

next if n4==n3 or n4==n2 or n4==n1

(0..(browser.size-1)).each do |n5|

next if n5==n4 or n5==n3 or n5==n2 or n5==n1

percentage_paid=q.partner_drm_share(1, browser[n1].last)

percentage_paid+=q.partner_drm_share(2, browser[n2].last)

percentage_paid+=q.partner_drm_share(3, browser[n3].last)

percentage_paid+=q.partner_drm_share(4, browser[n4].last)

percentage_paid+=q.partner_drm_share(5, browser[n5].last)

min=percentage_paid if min>percentage_paid

max=percentage_paid if max<percentage_paid

end

puts format "Min: %.1f %%", 100.0*min

puts format "Max: %.1f %%", 100.0*max

puts

puts "-------------------------------------------------------------------------------------------"

puts "Qworum revenue that would go to a particular browser provider, depending on seniority"

puts "(hypothesis: browser DRM usage == browser Enterprise usage == current browser market share)"

puts

(0..(browser.size-1)).each do |provider|

puts "#{browser[provider].first}:"

(1..browser.size).each do |seniority|

puts format " #{seniority}: %.1f %%", 100.0*q.partner_drm_share(seniority, browser[provider].last)

end

puts

puts "-----------------------------------------------------------------------------------------------"

puts "Browser market shares as of april 2011;"

puts "these are used in the partner revenue projections displayed above"

puts "(source: http://arstechnica.com/web/news/2011/05/web-browser-market-share-upgrade-analysis.ars)"

puts

(0..(browser.size-1)).each do |provider|

puts format "#{browser[provider].first}: %.2f %%", 100.0*browser[provider].last

end

Update: We also share up to 20% of our Service Provider revenue with our partners (providers of Qworum APIs need to purchase Service Provider subscriptions from their hosting providers). Technically, our DRM revenue includes both marketplace commissions and Service Provider subscriptions.

Browser providers as Qworum partners

2011-10-19T21:03:00.000+02:00

I will briefly talk about the benefits of having Qworum implemented natively by browsers.

Currently, Qworum is only available as add-on for various web browsers. While this situation might be satisfactory in controlled environments such as private enterprise networks where deployment is less of an issue, this makes Qworum use on internet websites problematic.

Our position regarding Qworum deployments is this:
Qworum interpreters really need to become as commonplace on browsers as HTML renderers. For that, browsers would ideally implement Qworum natively.

Encouraging native implementations is core to our strategy:

Qworum specifications are open, so that browser providers can contribute to them. They can suggest bug fixes for the current versions, as well as new features for future versions.
Qworum specifications are free to implement on the client-side. In fact, they are better than free - we have a revenue sharing program that browser providers can participate in.

The role of Armangil Software primarily consists of operating the back-end servers that handle monetary transactions.

Here is a Quora question on this subject.

Update: To further clarify the way our revenue sharing program works, compensation is structured in a way that rewards early partners, as well as partners with more market share. Our goal is to incentivise browser providers to take swift action on our business proposal.

Hybrid applications and Google's Native Client

2011-10-11T17:46:00.000+02:00

I don't think there is any doubt that Google is a force to be reckoned with, in terms of browser innovation. Case in point: the Native Client platform, which allows native code to run inside the browser. Native Client offers a clear path for porting desktop applications to the browser.

Google's main arguments for selling the Native Client platform to developers is security and ease of deployment (through the Chrome Web Store). The jury is still out on how well these arguments will be received - Windows users have lived with security issues forever, and there are rumours of an upcoming Windows application store.

My suggestion for improving Native Client:
The Native Client platform should become more web-friendly, by supporting hybrid applications. It could so gain a definitive edge over desktop platforms.

To clarify: hybrid applications are Native Client applications that can call interactive web services (and so use individual features of online web applications).

Interactive service calls would execute in browser tabs, as follows:

1. An overlay would appear in the browser tab containing the Native Client application making the call, thereby temporarily preventing its use.
2. A new browser tab would be created, where the service would execute.
3. The end-user would interact with the service through regular web pages.
4. When the service call terminates, the new tab would close.
5. Finally, the tab containing the Native Client application would have its overlay removed, and the application would again become responsive.

Probably the only service technology available today for enabling this scenario is Qworum, so it arguably deserves a look from the Native Client team.

Update: Posted a Quora question on this subject.

Of humans and machines

2011-10-10T18:01:00.000+02:00

Since the early days of computing, there has been a dichotomy, or at least a continuum, between data that is intended for human consumption, and data that is intended for machine consumption.

Here is a sample of how that continuum manifests itself in web formats, ordered by human-friendliness:

Web page (primarily intended for humans);
Web page with microformats (human-friendly data that contains machine-friendly data);
RSS feed (machine-friendly data that contains human-friendly data); and
XML-RPC result message (primarily intended for machines).

Similarly, there is a continuum between services that are intended for human consumption, and services that are for machine consumption. Here is a sample:

Website / Web application (primarily intended for humans);
Qworum service (for both humans and machines);
XML-RPC service (primarily intended for machines).

While this argumentation might seem philosophical, it is in fact of practical use for systems design. For example, this line of thinking has allowed Qworum to support both web browsers and RPC clients for consuming services.

The end-user as a resource

2011-10-10T00:12:00.000+02:00

I will briefly talk about the way the end-user is modeled in Qworum, and the benefits of the Qworum approach.

In Qworum, the end-user is considered as a resource that services can make use of during their execution.

Here is how a Qworum service "calls" the end-user resource:

It sends back a web page as response to a request,
The request which is in turn generated from this page (e.g. through an end-user click) is effectively the result of the end-user call.

Considering the end-user as a resource has one immediate benefit: it becomes possible for services to continue their execution in the end-user's absence. In fact, Qworum has a built-in mechanism for that:

Qworum user-agents throw a "user" fault (i.e. exception, in Qworum-speak) when they receive a web page, and the end-user is not present. Services can catch and handle that fault to continue their execution.

This approach allows Qworum to support both interactive user-agents such as web browsers, and non-interactive user-agents such as RPC clients.

A next-generation service platform named Qworum

2011-10-07T20:23:00.000+02:00

I would like to briefly present here a service platform which I have been working on.

Simply said, Qworum is a platform that supports interactive web services. In other words, Qworum services can interact with the end-user through conventional web pages, while still showing RPC service behaviour (i.e. they receive call arguments and they return a result).

So Qworum is neither a web technology, nor an RPC technology; it is both!

Qworum compared to the World Wide Web

The World Wide Web was designed as a system of interlinked documents. In contrast, Qworum is a system of interlinked services.

I believe that in today's web, which is increasingly being used to provide applications, there is a currently unmet need for a technology such as Qworum which allows for modular web applications.

Qworum compared to XML-RPC

XML-RPC may well be the most practical RPC system available today, so my observations will be based on that.

Qworum is a service technology that supports point-to-point RPC calls, as does XML-RPC. Additionally:

It has support for interactive services,
It supports many types of clients: services can be called by web applications and other services, as well as by RPC clients,
It supports XML data: services can receive and return raw XML, as well as RPC-style data that can be deserialized into native constructs for various programming languages.
It identifies services by their URL, instead of providing its own identification mechanism.

The reason for Qworum's ability to offer such an extensive list of features is its leveraging of all existing web standards.

Read the full Qworum specification here.