ObjectSpaces: The Power of the Dot
When the ObjectSpaces project was first getting underway, back when the team consisted of just myself and Luca, there was a strange sort of awakening that occurred. One that can only be described as the sudden realization and belief in the power of the dot.
Now, I'm not intending to steal the thunder from any company that wants to be known as the dot in dot-net or some such inanity. I'm talking about the true, honest to God, DOT. The dot in your code.
You see the ObjectSpaces project was born as an infant from its data-access (ado) and xml parents. We were trying to complete the trinity of data; relational, xml and objects. Today Erik Meijer likens these to rectangles, triangles and circles respectively.
We started out thinking that we ought to leverage as much as possible from the current framework, so the first prototype of ObjectSpaces was built over the dataset. What was shown at the PDC a couple of years ago was pretty much this, except there was not much of my original code left in it after turning over to Jason and his team. In fact, the most current codebase doesn't even recognize me anymore. When I go to see it, it shies away behind Jason and Luca.
Anyhow, we also knew that query would be very important for this new thing. Too many attempts in the past tried treating persistent objects as things you could only retrieve given a reference or key. We knew we had to do better, and we knew we had the perfect language already.
You see, XML and objects were pretty similar. After talking to a lot of customers that worked with objects in data-access layers or with other persistence technologies we found that stored objects were very much graph-like in nature; meaning there was a lot of hierarchy that could be accessed from a variety of directions. Sometimes, though, all you had was a starting point, and so the only way to ask any meaningful question of the data was to query into it from that one point. This was very different than relational data that is always broken down into distinct tables. However, XML was very much like this object data. XML was a pure tree structure, but a query language like XPath was ideally suited for drilling down though structure.
We had XPath. Heck, we had just written probably the fastest XPath processor on the planet. It was no great leap of logic to see that XPath would be the ideal language for querying graphs of objects. So I set out to purloin the XPath parser and execution engine into my project folder. When I was done I could use the xpath engine to query objects in memory and a translator I wrote to query objects stored in SQL server. Everything seemed peachy.
Then we showed our wondrous invention to a variety of customers under NDA. Most of them already had experience using object persistence technologies, so they pretty much knew what they wanted to build. However, when it came to the point of writing the queries they were perplexed. “What's this XPath thing?” Luca showed them some queries, but they all but scratched their heads. You see, they didn't much know about XML or XPath at this point. Even the ones that did found it a very difficult leap to make, transitioning the understanding of their object model into an XML schema and back. It just wasn't natural.
That's were we had made our mistake. We innocently assumed that since we were trying to unify all of relational, xml and objects into one tidy unit, our customers would too. Except they weren't. As it turns out for many of them, the whole point of writing their own abstraction layers over ADO or using a persistence technology was to be able to remove themselves from the nitty-gritty of data storage, so they could focus on their applications, all of which were expressed in terms of their own objects.
They only wanted their 'application programmers' messing with their objects, and not to be bothered with details about how the information is stored or expressed in other forms. They wanted their programmers concerned with the business logic and the code they were writing.
That's were the inspiration came from. I deduced that the problem that was hanging them up was the awkward slash notation of xpath and the angle brackets of XML. They were unnatural because they didn't fit into their world view of what they did. They wrote code in languages like VB or now C#. If the query language looked like their code and the data representation in the query always looked like the objects as defined in their programming language it would be a much more natural fit.
So I went to work. I went into the code and started to make some changes. For one, all tag names changed to property names. That's what you do in code, you access properties. And the big change for the parser, I changed the slash to a dot. That's it. Now to be truthful, the language has changed considerable since that day. It has become much more formalized and is now very different from XPath, but back then that's all it was.
We took the prototype back to the same customers. Low and behold, they 'got it'. Without any documentation at all, after only a brief example they were off writing their own queries. It was like magic. It was the dot, stupid.
Now that's power.