That will obviously required a cloud-based data repository.
Talking with my colleagues, all of their suggestions were oriented towards the Microsoft Azure and Amazon solutions discussed so far on the
cloud and mobile DevBlog.

I was searching for something freer, more open source, and less proprietary, and was rather surprised to discover an utterly relaxing solution that so far looks absolutely perfect for me and my needs.

I first stumbled upon IrisCouch, which led me to CouchDB and NoSQL, which all make me very happy.
For didactical purposes, I will discuss them in inverted order, though.

Before I get to that, I would also like to mention my first ski tour of the year:

My Ski Tour Season Opening

I went on a ski crossing of the Glarner Alps last weekend.

We took the cable lift up to the Fisetenpass and climbed the Gemsfairenstock, Clariden and Piz Cazarauls.
We were hoping to get on to the Schärhorn as well, but had to give that up due to bad weather conditions.
Instead we headed over the glacier to the Chammlijoch und down the Iiswaendli back to the Klausenpass.

This was my second ascent of the Clariden Mountain, following the
last one in
September 2011, from the opposite direction and obviously under very different conditions.

A great way to get away from computers for a day or two and face the natural elements instead, at their wildest and fiercest.

Relax – with NoSQL

A NoSQL database provides a simple, lightweight mechanism for storage and retrieval of data that provides higher scalability and availability than traditional relational databases.
The NoSQL data stores use looser consistency models to achieve horizontal scaling and higher availability.
Some NoSQL systems do allow SQL-like query language to be used.

NoSQL database systems are often highly optimized for retrieval and appending operations and often offer little functionality beyond record storage, e.g. key–value stores.
The reduced run-time flexibility compared to full SQL RDBM systems is compensated by marked gains in scalability and performance for certain data models.

Since my application will only require storage of simple key-value pairs and should in theory be massively scalable, this sounds like an optimal choice.
In practice, I only expect it to be a toy, of course; the scalability is required only to make it a useful example toy.

Relax – with CouchDB

Apache CouchDB is
a NoSQL implementation, one of a new breed of database management systems.

As stated by its official by-line, the one word to describe CouchDB is relax.
When you start CouchDB, you see:

Apache CouchDB has started. Time to relax.

CouchDB is built not only for, but of the Web.
Its design borrows heavily from web architecture and the concepts of resources, methods, and representations.
Data is self-contained:

Replication and backup is extremely simple, basically requiring no more than a modification of the base URL.

CouchDB is implemented in the
Erlang programming
language, which is used to build massively scalable soft real-time systems with requirements on high availability with uses in telecommunication, banking, e-commerce, computer telephony and instant messaging.
Erlang's runtime system has built-in support for concurrency, distribution and fault tolerance.

Relax – with IrisCouch

As I initially mentioned, the starting point of this exploration of mine was
IrisCouch,
which terms itself 'easy CouchDB'.
It provides a free hosting service, 'a couch in the cloud'.
You can sign up in minutes to have your own Apache CouchDB server.

For my purposes, I can install CouchDB on my local machine, develop my data repository locally, and push it all to the cloud by replicating my local database to IrisCouch and changing the base URL to use that for all interaction.

Relax – with DreamSeat

While I explored the theory, my colleague
Philippe Leefsma went
ahead and implemented a pair of .NET applications uploading and consuming cloud-based data from an IrisCouch-hosted CouchDB database using the
DreamSeat CouchDB .NET wrapper library.

Although the DreamSeat documentation boasts support for both complete synchronous and asynchronous API, Philippe used Visual Studio 2012 and its .NET 4.5 async support that automatically and transparently implements the entire support for async call-back.
'Async' methods can use the 'await' keyword, so he wrote a couple of anync wrapper methods for standard synchronous DreamSeat calls.

Well, that provides lots of material to play with in the immediate future, and gives me hope of easily implementing my cloud-based data repository requirements.

Here are a couple of other more directly Revit API related notes:

ID and GUID in Revit Documents

Question: A short question about the way unique ID’s are managed in Revit.
I want to export a large number of RVT models through DB link to a single database and I really need to have unique ID’s in my destination tables.
So far what I’ve seen is that the records pushed to my database have a field ID which seems to be unique within each Revit file, but not with my set of files.

So is there a way to have really unique identifier like a GUID instead of simple ID in my RVT models?
Or at least is there a way to rely on a kind of GUID when we push data through DB link?

Answer: Each Revit element has an ID property, its element id, which is unique within the RVT document, but not globally.

Visual Revit Programming with Dynamo

One last, final note before closing: if you are interested in a visual programming environment for Revit which allows non-programmers to create workflows to automate Revit functionality and geometry creation, be sure to check out
Dynamo, also featured at
AutodeskVasari.com.

That will obviously required a cloud-based data repository.
Talking with my colleagues, all of their suggestions were oriented towards the Microsoft Azure and Amazon solutions discussed so far on the
cloud and mobile DevBlog.

I was searching for something freer, more open source, and less proprietary, and was rather surprised to discover an utterly relaxing solution that so far looks absolutely perfect for me and my needs.

I first stumbled upon IrisCouch, which led me to CouchDB and NoSQL, which all make me very happy.
For didactical purposes, I will discuss them in inverted order, though.

Before I get to that, I would also like to mention my first ski tour of the year:

My Ski Tour Season Opening

I went on a ski crossing of the Glarner Alps last weekend.

We took the cable lift up to the Fisetenpass and climbed the Gemsfairenstock, Clariden and Piz Cazarauls.
We were hoping to get on to the Schärhorn as well, but had to give that up due to bad weather conditions.
Instead we headed over the glacier to the Chammlijoch und down the Iiswaendli back to the Klausenpass.

This was my second ascent of the Clariden Mountain, following the
last one in
September 2011, from the opposite direction and obviously under very different conditions.

A great way to get away from computers for a day or two and face the natural elements instead, at their wildest and fiercest.

Relax – with NoSQL

A NoSQL database provides a simple, lightweight mechanism for storage and retrieval of data that provides higher scalability and availability than traditional relational databases.
The NoSQL data stores use looser consistency models to achieve horizontal scaling and higher availability.
Some NoSQL systems do allow SQL-like query language to be used.

NoSQL database systems are often highly optimized for retrieval and appending operations and often offer little functionality beyond record storage, e.g. key–value stores.
The reduced run-time flexibility compared to full SQL RDBM systems is compensated by marked gains in scalability and performance for certain data models.

Since my application will only require storage of simple key-value pairs and should in theory be massively scalable, this sounds like an optimal choice.
In practice, I only expect it to be a toy, of course; the scalability is required only to make it a useful example toy.

Relax – with CouchDB

Apache CouchDB is
a NoSQL implementation, one of a new breed of database management systems.

As stated by its official by-line, the one word to describe CouchDB is relax.
When you start CouchDB, you see:

Apache CouchDB has started. Time to relax.

CouchDB is built not only for, but of the Web.
Its design borrows heavily from web architecture and the concepts of resources, methods, and representations.
Data is self-contained:

Replication and backup is extremely simple, basically requiring no more than a modification of the base URL.

CouchDB is implemented in the
Erlang programming
language, which is used to build massively scalable soft real-time systems with requirements on high availability with uses in telecommunication, banking, e-commerce, computer telephony and instant messaging.
Erlang's runtime system has built-in support for concurrency, distribution and fault tolerance.

Relax – with IrisCouch

As I initially mentioned, the starting point of this exploration of mine was
IrisCouch,
which terms itself 'easy CouchDB'.
It provides a free hosting service, 'a couch in the cloud'.
You can sign up in minutes to have your own Apache CouchDB server.

For my purposes, I can install CouchDB on my local machine, develop my data repository locally, and push it all to the cloud by replicating my local database to IrisCouch and changing the base URL to use that for all interaction.

Relax – with DreamSeat

While I explored the theory, my colleague
Philippe Leefsma went
ahead and implemented a pair of .NET applications uploading and consuming cloud-based data from an IrisCouch-hosted CouchDB database using the
DreamSeat CouchDB .NET wrapper library.

Although the DreamSeat documentation boasts support for both complete synchronous and asynchronous API, Philippe used Visual Studio 2012 and its .NET 4.5 async support that automatically and transparently implements the entire support for async call-back.
'Async' methods can use the 'await' keyword, so he wrote a couple of anync wrapper methods for standard synchronous DreamSeat calls.

Well, that provides lots of material to play with in the immediate future, and gives me hope of easily implementing my cloud-based data repository requirements.

Here are a couple of other more directly Revit API related notes:

ID and GUID in Revit Documents

Question: A short question about the way unique ID’s are managed in Revit.
I want to export a large number of RVT models through DB link to a single database and I really need to have unique ID’s in my destination tables.
So far what I’ve seen is that the records pushed to my database have a field ID which seems to be unique within each Revit file, but not with my set of files.

So is there a way to have really unique identifier like a GUID instead of simple ID in my RVT models?
Or at least is there a way to rely on a kind of GUID when we push data through DB link?

Answer: Each Revit element has an ID property, its element id, which is unique within the RVT document, but not globally.

Visual Revit Programming with Dynamo

One last, final note before closing: if you are interested in a visual programming environment for Revit which allows non-programmers to create workflows to automate Revit functionality and geometry creation, be sure to check out
Dynamo, also featured at
AutodeskVasari.com.