NexusDB

In this post I'll take a look at a concept called interface aggregation.

It's the last major piece required to understand the design and implementation of NexusRemoting and is also a useful technique to understand in general.

All of us Delphi developers are probably in the same boat when it comes to handling multiple projects each with different versions of different IDE packages. Package collisions, error messages and unloadable forms are a normality and to be blunt they are a pita. I used to solve that issue by running numerous VMWare sessions but the size of the disk images and the resources used by running several of these simultanously was huge.

But... there's another solution!

While the following knowledge is not strictly necessary to use NexusRemoting, it is needed if you want to understand how NexusRemoting actually works under the cover. Also, the information presented here is generally useful for anyone working with interfaces beyond the most trivial cases.

Delphi simplifies working with QueryInterface through the "Supports" functions in SysUtils:

Before I can go into the details of the Remoting system as implemented by NexusRemoting it's important to have a common understanding of Interfaces in Delphi. This post will explain the fundamental concepts involved with Interfaces in Delphi.

When reading the above paragraph closely it should jump out that I'm qualifying "Interfaces" with "in Delphi". Interfaces as a general concept are implemented by many programming languages and platforms in different ways. Within the context of Delphi Interfaces are based on the definition of interfaces from COM.

In NexusDB communication between Client and Server is facilitated using the Transport components. These Transports implement a bidirectional, multi-thread aware, message exchange mechanism.

Want to share some experience regarding quality assurance & testing in .NET here.

Fortunately this Monday morning, when I was just about to sign the ADO.NET provider off for release, I got some second thoughts whether the 114 test cases (using NUnit) in the test suite would be enough to ensure quality. While the tests had been more than doubled compared to previous releases, I was concerned about the coverage of these tests.

In this last week I've been working on the VS 2005 integration for our ADO Provider. Everything was going smooth. First ... then came testing on different real world machines and VM's. And suddenly there was nothing but trouble. After some busy hours bug fixing and retesting I was down to one obvious problem. One some machines it would happen that at the end of the "New Datasource Wizard" an error "Failed to find or load the registered .NET framework data provider." appeared deep in VS code territory.

A major omission in current NexusDB versions is user/access control. There's only very limited server based support for read, write and administration rights. For the majority of tasks this is enough, but how would it be if a full featured control system like in SQL Server or Oracle would be available?

It seems that there's a common belief that 64-bit is going to generally make applications and server applications faster. But it's not that simple and actually most well written 32-bit applications will be slower when ported and recompiled for 64-bit. Why that?

That's a good question for a database engine. While it's essential for good performance to cache data in memory, it's also a bad idea to fill up memory with useless cached data.