Universal Data Access Technology Blog

OpenLink Software Releases new Universal Data Access Driver Suite 6.1

Sun, 20 Jan 2008 13:38:14 GMT

  New ODBC, JDBC, ADO.NET, and OLE DB Drivers for Major Databases

Burlington, MA. Tuesday, January 15, 2008 - OpenLink Software, Inc., technology leader in the development and deployment of secure, 
high-performance universal data access middleware, announces the commercial availability of Release 6.1 of its high-performance and 
secure Universal Data Access Drivers.  

The updated components support new and older releases of Oracle, Microsoft SQL Server, Sybase, IBM DB2, IBM Informix, Ingres, Progress
Open Edge, MySQL, PostgreSQL, and Firebird, across Windows, Mac OS X, Linux, Solaris, HP-UX, and AIX.

New features across then entire suite include:

- XA-based two-phase commit across ODBC, JDBC, and ADO.NET

- Microsoft SQL Linked Server compatible ODBC provider for OLE DB (32 & 64 Bit)

- ODBC Bridge for JDBC accessible Databases (32 & 64 Bit)

- Ruby on Rails Adapter for ODBC- and JDBC-accessible databases

- Support for 64-bit Windows running on x86_64 (e.g., Opteron, Xeon) and IA64 (e.g., Itanium2) Processors across all Data Access APIs -- 
   ODBC, JDBC, OLEDB,  and ADO.NET

- Support in Mac OS X Universal binaries for PPC and Intel 32-bit mode on Tiger (10.4) and Leopard (10.5), plus Intel 64-bit mode on Leopard

- ADO.NET 2.0 Support (and an ADO.NET 3.0 Beta Provider on request)

- ADO.NET integration with Visual Studio 2005 

"The new product release builds on our legacy as leading provider of quality, secure and high-performance data access drivers to all major
DBMS engines," said Kingsley Idehen, President & CEO.

"We are at a critical juncture within the enterprise and across the Web, where data access, portability, and unobtrusive integration require
the technological prowess and leadership qualities we've consistently demonstrated over the last 15 years. Standardized data access
middleware that enables the development and deployment of database and operating system independent applications remains a critical priority
for organizations worldwide," he added.

About OpenLink Software
=======================  

OpenLink Software is a privately held software company with offices in the U.S.A., United Kingdom, Russia, and Bulgaria. It has been the
leading provider and technology innovator in the universal data access middleware market since 1993, with over 10,000+ companies currently
using its products worldwide.

Additional information on OpenLink Software can be obtained from the web site: http://www.openlinksw.com/.

Contact:
Helen Heward-Mills,
OpenLink Software, Inc.
Tel: 781 273 0900
Email: hmills@openlinksw.com

Announcing ODBC Data Adapter for Ruby on Rails, release 1.1

Mon, 23 Oct 2006 17:03:03 GMT

OpenLink Software are pleased to announce release 1.1 of the ODBC Adapter for Ruby on Rails (ActiveRecord).

This unifies data-access from a plethora of individual adapters to one common configuration in Rails; rather than having a multitude of DBMS-specific Rails Adaptors with inconsistent functionality and behaviour, you can now focus on a single data adapter with consistent behaviour across ODBC-accessible databases on all Ruby-supported platforms. This release adds support for DB2, MySQL, Sybase and SQL Server. The supported DBMSes now include: Oracle, Informix, Ingres, OpenLink Virtuoso, SQL Server, Sybase, MySQL and DB2.

The adapter can be downloaded from rubyforge: http://rubyforge.org/projects/odbc-rails/

Technorati Tags: odbc, rails, ruby, webdevelopment

Why Web 2.0 clones are not innovative

Mon, 23 Oct 2006 16:02:56 GMT

Why Web 2.0 clones are not innovative:

Richard MacManus at ZDNet writes his view on Web 2.0 clone applications. He observed that every country has its set of Web 2.0 clones — bookmarking sites that looks del.icio.us, photo sharing sites that like Flickr, social networking sites like MySpace, community news sites like digg, etc. He criticizes those Web 2.0 clones being non-innovative.

It’s true that most of the clone apps don’t come with innovative ideas, but it would be unwise to think that they totally have no values. Contrary to Richard’s point of view, I think clone apps are essential ingredients in helping the IT business in developing countries to become innovative.

Innovative ideas don’t usually born in the thin air. They requires extensive testings and experiments. The mature IT business in the US has extensive knowledge and experience in developing innovative ideas. People here have a general idea about what works and what doesn’t. In many developing countries, however, the settings are completely different.

Take China for an example. Its IT market is still in an infant stage comparing to that of the US. Chinese businesses that recently entered the market are still in the stage trying to figure out how to make profits and establish a sustainable business model. The need to be innovative now, perhaps, is not on the todo lists of the business executives.

Furthermore, the past generation of Chinese engineers and developers were not exactly trained to be innovative and think outside-the-box. They were trained with impressive memorization skills and obey orders from superiors. It’s unfair to expect this generation of Chinese IT workers to live and breath with innovations as their US counterparts do.

Given this type of harsh environment in many developing countries, it’s quite natural to act as copycats and repeat business ideas that have good track records. In fact, it’s a good business if being a copycat can bring profits.

We don’t criticize Yahoo! Maps being a copycat of Google Maps. We don’t criticize Google Notebook being a copycat of del.icio.us. Why should we criticize foreign Web 2.0 clones when their intention is to learn how to enter a global IT market and to become prosperous? Maybe in the cloning process, copycats will discover innovative ideas by accident.

Technorati Tags: business, web2.0

What Problem Does Natural Language Search Solve?

Mon, 23 Oct 2006 16:02:55 GMT

What Problem Does Natural Language Search Solve?:
Matt Marshall recently posted a story about a new search engine looking to raise a lot of money at a very high valuation, which has created quite a bit of buzz as people argue over whether or not the company has a chance, or deserves such a high valuation. Matt followed up with more details on the company, though he still expresses some reasonable skepticism. Like many people, my first reaction on hearing about it was that I can't remember a year that's gone by without someone claiming to have come out with a revolution in natural language search. However, when it comes to search engine news, no one can go through the history and explain why something is a bad idea quite like Danny Sullivan can. He lists out all the attempts at natural language search, and shows how each one failed (in some cases, miserably). He also points out that the problem with natural language search is that it requires everyone to change their behavior. As with any startup, when you're looking at their chances, the big question to ask is pretty simple: what problem does it solve? Plenty of people have figured out how to search with keywords. In fact, many of us find it more natural and faster than trying to construct a natural language query. So, while all the natural language search engines that come along insist that searches suck because they can't understand the the searcher, it's not clear that's the real problem. When people want to use a search engine, they want to find what they want. That means being able to search quickly. Dumping two or three keywords into a box is always going to be a lot faster than figuring out the natural language equivalent. So, perhaps someone can enlighten us. What is the problem natural language search solves?

Technorati Tags: search

(via Techdirt)

Technorati Tags: natural-language, search

Planning the Software Industrial Revolution

Fri, 13 May 2005 17:33:19 GMT

Here is another timeless article by Brad Cox titled: Planning The Software Industrial Revolution.

Enjoy!

Social Construction of Reality

Fri, 13 May 2005 11:31:42 GMT

An interesting article by Brad Cox. (inventor of Objective-C) that's provides great foundation for a understanding number of issues that are relevant to social networking systems.

Standards Contempt Revisited

Thu, 12 May 2005 15:11:14 GMT

My entire time in the IT industry has been spent primarily trying to develop, architect, test, mentor, evangelize, and educate about one simple subject: Standards Appreciation!

The trouble with "Standards Appreciation" is that vendors see standards from the following perspectives primarily:

Yet another opportunity to lock-in the customer
If point 1. fails then undermine the standard vociferously (an activity that takes many covert forms; attack performance, security, and maturity)
Developers don't like standards (the real reason for this is to-do lists and timeframes in most cases)

Korateng Ofusu-Amaah provides insightful perspective on the issues above, in a recent "must read" blog post about how this dysfunctionality plays out today in the realm of HTML Buttons and Forms. Here are some notebable excerpts:

"Instead my discourse devolved into a case of I told you so, a kind of Old Testament view of things instead of the softer New Age stylings that are in vogue these days. Sure there was a little concern for the users that had been hurt by lost data, but there was almost no empathy for the developers who had to lose their weekends furiously reworking their applications to do the right thing especially because it appeared that they would rather persist in trying to do the wrong thing.

The sentiment behind that mini tempest-in-a-teapot however was a recognition of the fact that those who have been quietly evangelizing the web style were talking about the wrong thing and to the wrong people."

...

"..As application developers we should ask for better forms, we should be demanding of browser makers things like XForms or Web Forms 2.0 to make sure that we can go beyond the kind of stilted usability that we currently have. Our users would appreciate our efforts in that vein but for now, they know what to expect. Until then application developers should push back when we are told to "do the wrong thing".

There is an unfortunate mindset trend at the current time that espouses: "Sloppiness" is good, and "Simple" justifies inadequacy at all times. Today, the real focus of most development endeavours is popularity first and coherance (backward compatibility, standards compliance, security, scalability etc.) a distant second, if you can simply make things popular then that justifies the sloppiness (acquisition, VC money, Blogosphere Juice etc.). Especially as someone else will ultimately have to deal with the predictable ramifications of the sloppiness.

Standards are critical to the success of IT investment within any enterprise, but standards are difficult to design, write, implement, and then comprehend; due to the inherent requirement for abstraction - it's a top down, as opposed to bottom up, process.

Vendors will never genuinely embrace standards, until IT decision makers demand standards compliance of them, by demonstrating a penchant for smelling out "leaky abstractions" embedded within product implementations. Naturally, this requires a fundamental change of mindset for most decision makers. It means moving away from the "this analyst said...", "I heard that company X is going to deliver....", "I read that .....", "I saw that demo..." approach to product evaluation, to a more knowledgeable evaluation process that seeks out the What, Why, and How of any prospective IT solution.

Knowledge empowers all of the time. It's a gift that stands the test of time once you invest some time in its acquisition (unfortunately this gift isn't free!). Ignorance with all its superficial seduction (free and widely available!), is temporary bliss at best, and nothing but heartache over time.

A Collection of PHP and ODBC How-To Links

Sun, 01 May 2005 15:46:45 GMT

In 2005 I am somewhat surprised at the steady level of emails and commentary expressing confusion about the use of PHP and ODBC.

Here are a few links that resolve any confusion about this matter:

OpenLink's PHP and iODBC HOWTO doc: http://www.iodbc.org/index.php?page=languages/php/odbc-phpHOWTO
PHP Everywhere's guide: http://phplens.com/phpeverywhere/node/view/9
Zili Zhang's piece from 1999 (time flies!): http://www.tldp.org/HOWTO/MSSQL6-Openlink-PHP-ODBC.html
Zend's ODBC Tutorial: http://www.zend.com/zend/tut/odbc.php

Or simple google on PHP and ODBC or PHP and iODBC ...

Point, Counterpoint: Mac OS X Is Great for Fortysomething Unix Hackers

Sun, 01 May 2005 14:31:01 GMT

There has been a lot of well deserved attention going the way of "Mac OS X Tiger". A the current time, a lot of this attention tends to focus on the consumer constituency comprised of Aunt Milly et al, designers, and new media aficionados. The Daring Fireball posts an article titled: Point, Counterpoint: Mac OS X Is Great for Fortysomething Unix Hackers . This particular post applies to OpenLink Software in general across a myriad of fronts, especially the essence of this excerpt:

On the surface, Grahamâs piece seems like a nice pat on the back to the Mac platform. But thereâs an implication in his piece that the worldâs most prodigiously talented programmers are only now switching (or switching back) to the Mac, when in fact some of them have been here all along. GUI programming is hard, and for GUI programmers, the Mac has always been, in Brent Simmonsâs words, âThe Showâ.

I.e. the idea that by the mid-â90s the Mac user base had been whittled down to âgraphic designers and grandmasâ is demonstrably false â someone must have been writing the software the designers and grandmas were using, no? â but I donât think itâs worth pressing the point, because I suspect it wasnât really what Graham meant to imply. And the main thrust of his point is true: there is a certain class of hackers â your prototypical Unix nerds â who not only werenât using Macs a decade ago, but whose antipathy toward Macs was downright hostile. And it is remarkable that these hackers are now among Mac OS Xâs strongest adherents.

Itâs another sign of Mac OS Xâs dual nature: from the perspective of your typical user (and particularly long-time Mac users), it is the Mac OS with a modern Unix architecture encapsulated under the hood; from the perspective of the hackers Graham writes of, it is Unix with a vastly superior GUI.

Read on....

Ajax, Hard Facts, Brass Tacks ... and Bad Slacks

Fri, 29 Apr 2005 20:11:22 GMT

By Mark Bierbeck:

Ajax, Hard Facts, Brass Tacks ... and Bad Slacks

A number of people have contacted me recently about Ajax [1] -- a catchy name -- coined to provide an umbrella term for a particular group of technologies used to build web applications. The use of the word comes from Jesse James Garrett in a recent blog [2], and describes a class of internet applications written using JavaScript in a browser. By using JavaScript these apps have full access to the DOM, and as a consequence are able to make all sorts of changes to the page that the user is interacting with, without having to go back to the server.

When the application does need to go back to the server -- to deliver some data and get a response -- the idea is to keep the DOM intact so that the user has a smooth experience. This means that all communication with the server needs to take place outside of the normal HTML form mechanism, since this would obviously replace the current page.

Ajax addressed this, with what it calls 'asynchronous-JavaScript' -- retrieve only the data you need, and then directly manipulate the DOM to get the effect you want. 'Asynchronous-JavaScript' accounts for the first few letters of the name, with the remainder being the obligatory 'X' for XML (although XML is not really key to this technology, and many of the applications that are often cited as Ajax-apps don't use XML as the data medium).

Buzzing

The response to Ajax has been pretty positive. In fact the only negatives have been either to suggest a change of name or to moan a little that "I've been doing this for years, why hasn't anyone noticed me?" (I won't put any links to those sort of articles, since they are a little embarassing -- after all, everyone has been doing this for years!)

Anyway, despite a couple of sour-pusses, the software community is almost universally excited, and the blog wires have glowed over the last few months with descriptions of Google Maps, GMail, and so on.

Just about everyone who has asked me about Ajax has expected me to be disappointed. Surely, they say, this makes the case for XForms weaker? But my answer is the exact opposite -- XForms and standards-based web applications are in every way superior to the techniques described as Ajax, since the whole raison d'Ãªtre of XForms and XHTML 2 is to address the very problems that Ajax-like techniques suffer from.

That may come across as a little bold...so perhaps I should explain.

From Workaround to Feature

We've all been using HTML mark-up for years now, and the language hasn't changed much in that time. As a consequence, the increasing demand for more complex web-pages has meant that the balance in our documents has shifted increasingly from vanilla mark-up to 'the workaround'.

Whether it's providing tooltips, dynamic/repeating data sections, or small portions of our page that change without having to request a new document, we've generally had to dive into script. But the shift from mark-up to script has meant that the mark-up language itself has been relegated to a mere carrier for programs.

Unfortunately this means that no-one gains -- it's annoying for the programmer to have to produce ever more convoluted spaghetti JavaScript to meet the demands of their audience, but it's also annoying for the non-programmer, who probably only wants a tooltip. And its particularly annoying for those who want to use documents on the web for more ambitious applications to find that most of the important stuff in a document is hidden away in script.

All is not lost, however, since this collection of 'workarounds' provides a rich source of real-life patterns that appear for authors and programmers, time and again. They may be workarounds, but they are much-needed ones.

The aim of the new generation of languages like XForms and XHTML 2 is to take these 'common patterns' and turn them into mark-up. Just like the HTML elements <a> and <form> pack an enormous amount of functionality into deceptively simple tags, so too can new declarative mark-up capture patterns that have emerged 'in the wild'.

(Note that this is the opposite of so-called folksonomies, where popular practice that occurs in the wild is left it the wild, and codification is regarded as a dirty word.)

The XML HTTP Request Object

Let's take the much talked about XML HTTP Request Object (XMLHttpRequest). If you are not familiar with it, it was originally part of Microsoft's XML parser, and allows you to send and receive data outside of the normal HTML form processing. Since it's a handy feature to have in a client, other browsers have followed suit and it's now becoming the 'standard' way to communicate with servers without messing up your page. It's a corner-stone of Ajax. (A good summary with examples is on Jim Ley's jibbering.com site [3].)

But...we need to be clear that we're using XMLHttpRequest to get round a weakness in HTML forms. The problem we have is that even if you know that a server is about to give you some data, and the server knows it's about to give you some data, there's no way to tell your form that -- instead your page will be wiped out and replaced with whatever the server sends back.

Of course, constant round-tripping doesn't make it completely impossible to produce applications, and a lot of books and airline tickets are bought every day without the facility to get 'just the data'. But we all know it would reduce network traffic and create a smoother user experience if we could just send a list of books or seats, rather than a whole new page.

Over the years applications such as Microsoft's Outlook Web Access (OWA), have had to step around the HTML form to get just the data they need. But, whilst OWA considerably predates GMail, until the advent of XMLHttpRequest, the techniques used were quite difficult to manage. (Google Suggest is often cited as a good example of an Ajax-app, but interestingly merges old and new techniques; XMLHttpRequest is used to obtain a piece of JavaScript from a server, and this script contains a call to a client-side function, but using server-provided parameters. It's one of the techniques you might have used in the past with a hidden frame.)

So as many have said on their blogs, XMLHttpRequest is not a newly devised technique, but rather a generally accepted replacement for a very old technique. But ultimately that technique is a workaround since the real problem is that HTML forms will always replace the current page.

Beyond HTML Forms

Whilst XMLHttpRequest gives us a way to get data to and from the server without losing our document, we've unfortunately thrown the baby out with the bath-water; whatever the weaknesses of HTML forms, you have to acknowledge that they are pretty simple to use. Here's an abbreviated version of Google's search form (note that the mark-up is HTML, not XML):


<form action=/search name=f>
  <input type=hidden name=hl value=en>
  <input maxLength=256 size=55 name=q value="">
  <input type=submit value="Google Search" name=btnG>
</form>

As you can see, the simple problem with HTML forms is that we don't say anything about where the data should go when we've received it from the server. The assumption in HTML of old is that we are just doing a kind of 'super-navigation', and no matter what we send to the server, it will only ever give us back a new web-page. (To put it a different way, you could say that <a> and <form> are pretty much the same thing.)

To see how this problem is resolved, let's code the same Google search in XForms:


<xf:submission id="sub-search"
 action="http://www.google.com/complete/search?hl=en"
 method="get" separator="&"
 replace="all"
/>


<xf:input ref="q">
  <xf:label>Query:</xf:label>
</xf:input>


<xf:submit submission="sub-search">
  <xf:label>Google Search</xf:label>
</xf:submit>

Although it will do exactly the same -- right down to replacing the current page -- it's a little different to the HTML mark-up. But the changes in structure have given us some major benefits, from accessible labels on our form controls, to the possibility of many different submissions for the same data.

But what it has also given us is the possibility of solving our data update problem. The replace attribute is actually optional in XForms, but I showed it in the previous mark-up so that you can compare it to this:


<xf:submission id="sub-search"
 action="http://www.google.com/complete/search?hl=en"
 method="get" separator="&"
 replace="instance"
/>

In this example the data returned from the server will just replace the instance that was sent, and our page will remain completely intact. (The replace attribute can take the values all, instance, or none.)

I won't show the full equivalent using XMLHttpRequest since it's pretty large, but I'll give a flavour of it. (Jim Ley's page -- referenced earlier -- shows how to search Google with XMLHttpRequest.)

The Script Version

First we need to create an XMLHttpRequest object, but we need to do it in such a way that it will work on both Mozilla and IE:


var req;


function loadXMLDoc(url) {
    // native XMLHttpRequest object
    if (window.XMLHttpRequest) {
        req = new XMLHttpRequest();
        req.onreadystatechange = readyStateChange;
        req.open("GET", url, true);
        req.send(null);
    // IE/Windows ActiveX version
    } else if (window.ActiveXObject) {
        req = new ActiveXObject("Microsoft.XMLHTTP");
        if (req) {
            req.onreadystatechange = readyStateChange;
            req.open("GET", url, true);
            req.send();
        }
    }
}

When a document is loaded via this function, the readyStateChange() method is invoked:


function readyStateChange() {
    // '4' means document "loaded"
    if (req.readyState == 4) {
        // 200 means "OK"
        if (req.status == 200) {
            // do something here
        } else {
            // error processing here
        }
    }
}

From a programming point of view, I guess you could say that there isn't a lot wrong with this, but then from a programming point of view there wasn't a lot wrong with Z80 or 6502 assembly languages -- I just wouldn't want to go back to them!

But the most important issue is that we have lost the very thing that was responsible for HTML's success -- the use of simple, clear, declarative mark-up, in which we simply state our intent, without having to write a program to do it for us. After all, the web took off because authors only had to master <a> in order to enter the exciting new world of 'hypertext' -- but XMLHttpRequest raises the bar again, and takes us right back into the heart of geek-world.

Beyond XMLHttpRequest

But in keeping with the principle that I outlined above -- that XForms and XHTML 2 try to provide mark-up for commonly existing design patterns -- let's see if there are any other patterns that XMLHttpRequest has thrown up.

You will have noticed in the earlier script that we had tests for success and failure:


if (req.status == 200) {
  // do something here
} else {
  // error processing here
}

XForms provides the same functionality through the use of events -- on success do this, on failure do that. This is far more powerful, since it hides the protocol-specific aspects of this code ("200" may be 'success' for HTTP, but it isn't 'success' when saving data to the hard-drive or sending an email).

XForms uses declarative mark-up to express those events, which again dramatically reduces coding:


<xf:action ev:observer="sub-search" ev:event="xforms-submit-error">
  <xf:message level="modal">
    Submission failed
  </xf:message>
</xf:action>

But there's lots, lots more in the submission part of XForms:

it can provide full XML Schema validation before submitting the data;

there is built in support for numerous types of serialisation, such as multipart/related;

abstract methods are used so the code is independent of protocol. For example, since put means the same thing whether the target URL begins http: or file:, a form with relative paths will run unchanged on a local machine or a web server;

it's extensible -- in formsPlayer 2.0 we have used the submission element to read and write from an ADO database, allowing programmers to convert forms from using the web to using a local database by doing nothing more than changing a single target URL. (Try doing that with XMLHttpRequest!)

The submission part of XForms is in fact so powerful that it will eventually form a separate specification, for use in other languages.

From Patterns to Mark-up

And there are plenty more patterns out there that were crying out to be turned into mark-up, and which are now incorporated into XForms and XHTML 2. Do you remember the days when if we wanted a tooltip that contained mark-up -- perhaps an image, or bold text -- we had to use a carefully placed <div>, a CSS display: none;, a mouseover event handler and a timer? Nowadays the programmer with better things to do than work with spaghetti-JavaScript just uses the XForms <hint> element, and for free they get platform independence (and therefore accessibility), as well as the ability to insert any mark-up.

And what about the days when we had to write code to open up a text-to-speech engine, and then invoke the various methods on the object to get it to speak its mind? Nowadays who wouldn't just use a CSS property on their XForms' messages?

Bad Slacks

And do you remember...I'm sorry, this one always makes me laugh...do you remember how we used to write lots of JavaScript to recalculate the shopping-cart when a new item was added? I know it's hard to believe -- it's like looking at old photos of us all wearing flares. Anyway, thank God for straight trousers and the XForms dependency-engine.

But enough of the good old days, the days of assembly language, C and JavaScript...let's stick with the new.

Do Try This at Home

To round all of this off, we'll take a look at Google Suggest, and we'll use XForms to implement it. I'll walk through the demo in a separate blog [4] so that this one doesn't get too cluttered -- and hopefully by disecting this simple but useful application, we can show how declarative mark-up scores over scripting.

[1] Will AJAX help Google clean up?, c|net, http://news.com.com/Will+AJAX+help+Google+clean+up/2100-1032_3-5621010.html

[2] Ajax: A New Approach to Web Applications, Jesse James Garrett, Adaptive Path blog, http://www.adaptivepath.com/publications/essays/archives/000385.php

[3] Using the XML HTTP Request object, http://jibbering.com/2002/4/httprequest.html

[4] "Google Suggest" Using XForms, http://internet-apps.blogspot.com/2005/04/google-suggest-using-xforms.html

Tags: xforms | xbl | webapps | ajax | javascript

[via Internet Applications]

Microsoft: Longhorn Is Great, XP Is Lame

Fri, 29 Apr 2005 16:11:01 GMT

Microsoft: Longhorn Is Great, XP Is Lame Software vendors walk a fine line when pushing upgrades -- tout the new version without slamming the old one. Microsoft threw that strategy aside in pumping Longhorn to the WinHEC faithful, as execs belittled Windows XP in the process. One VP said that XP hadn't been thought through and at times "failed to deliver." The surprising part is not that XP has major shortcomings -- early on its enhancements were recognized as little more than improved stability and a bunch of bug fixes. Rather, the interesting part is Microsoft actually admitting to drawbacks at all, even several years late. But Longhorn, now there's a real operating system!

[via Techdirt]

SAP, IBM Make Play for Oracle Database Customers With New DB2 Version

Thu, 28 Apr 2005 21:52:55 GMT

CNET reports:

There are a whopping 44,000 SAP customers running on Oracle databases, and IBM wants them. To get them, for the first time ever, it's optimized its enterprise database for a specific vendor's applications. The new version of DB, 8.2.2, will include a slew of SAP-optimized features, including self-tuning, self-configuration, silent install, dynamic storage allocation and more.

Wouldn't SAP be better served by simply making their application database independent via ODBC? This process really could have commenced years ago and prevented today's dilema: Your Partner has become Your most aggressive Competitor!

SAP tuned for specifically for DB2 or SAP tuned likewise for Microsoft SQL simply reeks of: "Same Sh*t different Pile". Microsoft and IBM will emulate Oracle in due course regarding their assault on SAP's market if DBMS specificity remains the SAP data access API strategy (this is a simple fact).

SAP should be using its quest for DBMS independence to stimulate or contribute ODBC enhancements (should ODBC be lacking in areas critical to its application needs; it is available in Open Source form and across all major platforms). Should the ODBC API not be the problem, then it can push ODBC Driver vendors (DBMS vendors such as IBM included) to get their Drivers in shape (should they be lacking, I know our ODBC Drivers are absolutely fine for this kind of task).

Database specificity gets application vendors nowhere. You can only control your business development destiny by being database independent. When applications are database independent the intellectual capital that drives your applications is preserved. This is akin to building physical and logical firewalls around the ecosystem created by your products. This is much better that being a pseudo DBMS engine reseller for a future competitor.

Advertising In RSS

Thu, 28 Apr 2005 19:56:05 GMT

Advertising in RSS is just starting now, for all practical purposes. If we wanted to, as an industry, reject the idea, we could.

[via Scripting News]

When XSL stylesheet integration becomes a standard feature across a majority of RSS readers the issue becomes moot. There is no need for industry wide rejection as this will ultimately come down to choice: "To Filter" or "Not To Filter".

Adsense based RSS Advertising as currently implemented (bearing in mind the fundamental intent to perpetuate obtrusive advertising in a popular new realm) is hillarious when you really come to think about it.

XML and Obtrusiveness are mutually exclusive. This attempt to inject advertising into RSS may go down as one of the greatest pieces of XML tutorial material of all time. It could also serve as yet another example of how Web 2.0 is fundamentally different from Web 1.0.

Will we ever truly comprehend the unadulterated meaning of: "Free Will" ?

A History Of Communications

Wed, 27 Apr 2005 21:17:55 GMT

A History Of Communications A History of Communications Timeline (via xBlog)

[via nixlog]

WebDAV, SQLX, and my Weblog

Tue, 26 Apr 2005 03:54:43 GMT

Uche Ogbuji comments in his blog about the use of WebDAV and SQLX in my blog as part of his commentary about Pyblosxom & WebDAV. To provide some clarity about Virtuoso and Blogging I have decided to put out this quick step by guide to the workings of my blog (there is a long overdue technical white paper nearing completion that address this subject in more detail).

Here goes:

Blog Editing

I can use any editor that supports the following Blog Post APIs:

- Moveable Type

- Meta Weblog

- Blogger

Typically I use Virtuoso (which has an unreleased WYSIWYG blog post editor), Newzcrawler, ecto, Zempt, or w.bloggar for my posts. If a post is of interest to me, or relevant to our company or customers I tend to perform one of the following tasks:

- Generate a post using the "Blog This" feature of my blog editor

- Write a new post that was triggered by a previously read post etc.

Either way, the posts end up in our company wide blog server that is Virtuoso based (more about this below). The internal blog server automatically categorizes my blog posts, and automagically determines which posts to upstream to other public blogs that I author (e.g http://kidehen.typepad.com ) or co-author (e.g http://www.openlinksw.com/weblogs/uda and http://www.openlinksw.com/weblogs/virtuoso ). I write once and my posts are dispatched conditionally to multiple outlets.

RSS/Atom/RDF Aggregation & Reading

I discover, subscribe to, and view blog feeds using Newzcrawler (primarily), and from time to time for experimentation and evaluation purposes I use RSS Bandit, FeedDemon, and Bloglines. I am in the process of moving this activity over to Virtuoso completely due to the large number of feeds that I consume on a daily basis (scalability is a bit of a problem with current aggregators).

Blog Publishing

When you visit my blog you are experiencing the soon to be released Virtuoso Blog Publishing engine first hand, which is how WebDAV, SQLX, XQuery/XPath, and Free Text etc. come into the mix.

Each time I create a post internally, or subscribe to an external feed, the data ends up in Virtuoso's SQL Engine (this is how we handle some of the obvious scalability challenges associated with large subscription counts). This engine is SQL2000N based, which implies that it can transform SQL to XML on the fly using recent extensions to SQL in the form of SQLX (prior to the emergence of this standard we used the FOR XML SQL syntax extensions for the same result). It also has its own in-built XSLT processor (DB Engine resident), and validating XML parser (with support for XML Schema). Thus, my RSS/RDF/Atom archives, FOAF, BlogRoll, OPML, and OCS blog syndication gems are all live examples of SQLX documents that leverage Virtuoso's WebDAV engine for exposure to Blog Clients.

Blog Search

When you search for blog posts using the basic or advanced search features of my blog, you end up interacting with one of the following methods of querying data hosted in Virtuoso: Free Text Search, XPath, or XQuery. The result sets produced by the search feature uses SQLX to produce subscription gems (RSS/Atom/RDF/ blog home page exists as a result of Virtuoso's Virtual Domain / Multi-Homing Web Server functionality. The entire site resides in an Object Relational DBMS, and I can take my DB file across Windows, Solaris, Linux, Mac OS X, FreeBSD, AIX, HP-UX, IRIX, and SCO UnixWare without missing a single beat! All I have to do is instantiate my Virtuoso server and my weblog is live.