New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Abel Avram on Jul 07, 2009
Microsoft has placed C# and CLI specifications, ECMA 334 and ECMA 335, under the Community Promise which basically protects anybody implementing them in any language and in any way from being sued by Microsoft for infringing corresponding intellectual properties or patents. This is directly related to Mono, the open source .NET implementation, whose legal status was unclear until now.
The Community Promise specifies:
Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation.
… The CP applies directly to all persons or entities that make, use, sell, offer for sale, imports and/or distributes an implementation of a Covered Specification. It is intended to enable open source implementations.
The Community Promise is less permissive than Open Specification Promise because the CP “requires that implementations conform to all of required parts of the mandatory portions of the specification.” but the developers still do not need to sign any license agreement with Microsoft or inform Microsoft about their work on implementing the C# and CLI specs.
Peter Galli, who made the announcement on Port25, explains the implications:
It is important to note that, under the Community Promise, anyone can freely implement these specifications with their technology, code, and solutions.
You do not need to sign a license agreement, or otherwise communicate to Microsoft how you will implement the specifications.
The Promise applies to developers, distributors, and users of Covered Implementations without regard to the development model that created the implementations, the type of copyright licenses under which it is distributed, or the associated business model.
Richard M. Stallman, the GNU father, warned about including Mono in open source projects only a week ago:
Debian's decision to include Mono in its principal way of installing GNOME, for the sake of Tomboy which is an application written in C#, leads the community in a risky direction. It is dangerous to depend on C#, so we need to discourage its use.
The problem is not unique to Mono; any free implementation of C# would raise the same issue. The danger is that Microsoft is probably planning to force all free C# implementations underground some day using software patents.
… We should systematically arrange to depend on the free C# implementations as little as possible. In other words, we should discourage people from writing programs in C#. Therefore, we should not include C# implementations in the default installation of GNU/Linux distributions or in their principal ways of installing GNOME, and we should distribute and recommend non-C# applications rather than comparable C# applications whenever possible.
Miguel de Icaza reported asking Microsoft to clear up Mono’s licensing issues:
A few months ago we approached Bob Muglia and Brian Goldfarb at Microsoft with a request to clarify the licensing situation for the ECMA standards covering C# and the CLI.
Since Mono is not just the implementation of the two ECMA standards, Icaza considers as necessary that
In the next few months we will be working towards splitting the jumbo Mono source code that includes ECMA + a lot more into two separate source code distributions. One will be ECMA, the other will contain our implementation of ASP.NET, ADO.NET, WinForms and others.
Depending on how you get Mono today, you might already have the this split in house or not.
Placing C# and CLI under the Community Promise assures open source developers and Linux distributors that Microsoft will not sue them for implementing the specs or for including Mono in their distributions. Until now, only VBA Language specification, HealthVault Service specification, UI Automation 1.0, and XPS specification 1.0 were covered by CP.
It still seems to be quite restrictive.
One question is: how hard it is to be fully compliant? "requires that implementations conform to all of required parts of the mandatory portions of the specification".
What happens if the specification changes? How can the specification change, and who can change it?
!
I agree - this is good news. The future is on both this platform and the JVM, so I'm glad to see that Microsoft is making their licensing less restrictive.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
3 comments
Watch Thread Reply