Q&A on MVSP from TigerLogic

People are asking questions about the new MVSP connectivity from TigerLogic. I’ll try to answer some of them here. This isn’t intended to be an exhaustive comparison, just an attempt to clarify where this option fits.

The MVSP name identifies a server connection interface for which there are two libraries for creating clients – there is a MVSP library for Java, and one for .NET. In addition, the same client code can be used for D3 v9.x or for mvBase v3.x. So, you can create a Java client for D3, a .NET client for D3, a Java client for mvBase, and a .NET client for mvBase.

MVSP should be of interest to you if one of the following statements is true:

• You are a Java or .NET developer and you work with D3 or mvBase.
• You have applications supported over D3 or mvBase and you are considering external connectivity.
• You already use the D3 Class Library, mv.NET, or some other package, and you’d like to know if you should use this new thing or if you should stick with what you have.

If you do not write Java or .NET code (C#, VB.NET, F#, or any of 30 other languages that implement the .NET Framework) and you don’t see yourself hiring anyone who does, then chances are MVSP won’t mean anything to you.

When I first heard about MVSP, I understood that one of the goals was for the Java and .NET libraries to be very close in terms of properties and method signatures, but it doesn’t look like it was really implemented like that. The libraries are very similar, but they are different enough where trying to transfer your knowledge of one to the other is probably going to be more difficult than just learning each on its own. (It would be nice to know why they diverged when there was such a great opportunity to keep these libs in sync.)

Should I use Java or .NET with MVSP to connect to my DBMS?

Use the right tool for the job, and use the tool with which you are comfortable, but be honest about why you’re using specific tools. The Java versus .NET debate is nothing more than techno-religion, but I still see people trying to put forward plans to completely re-write existing applications in “the other” technology, as if there is any positive gain. They are virtually equal in capability. People who push on any one side as being “the best” are too focused on their own comfort zone and less focused on solving specific problems. Acknowledging that one simply prefers .NET or Java is a better approach than trying to convince management that all existing code needs to be re-written for reasons that only the developer understands. If Java is indeed the right solution to a specific problem, no one should push .NET, and vice versa. If all of your software is already written in .NET, it may not make sense to start new development in Java. The right tool for each given problem can only be assessed by people who understand each of the tools in the kit.

Here’s another tip: If a Linux web server is to be used, the MVSP Java library may be more appropriate because it can connect from Linux or Windows, to a Linux or Windows-based D3, or mvBase over Windows. It can do this without a Windows middle-tier. If a Windows web server is being used, like IIS, then either Java or .NET can be used. If you’re using Linux/Unix, maybe with Apache, then Java is probably your best option.

If you’re looking for a free way to learn Java using MV connectivity as your vehicle, then MVSP is a great way to do it. MVSP is also a good free vehicle for learning how .NET connectivity can work with your D3 or mvBase system.

What’s the difference between MVSP and the D3 Class Library?

I think there are two significant answers to that. First, the MVSP library for .NET is fully “managed” which means it’s a real .NET library, which the D3CL is not, and that has been a source of pain for many developers. Second, the D3CL facilitates ODBC queries and processing recordsets, which MVSP does not. If you’re using ODBC with D3 then you still need your C34 client component, the D3 ODBC server, etc.

What’s the difference between MVSP and mv.NET?

The MVSP connection to the DBMS with either Java or .NET is generally non-persistent. You open the connection, do your transaction, and then close. This is equivalent to doing a login each time the connection is used. This can be a performance issue and is not suited for high activity environments.

mv.NET opens a single connection, now with Telnet or MVSP/.NET, and it keeps that connection open. When a transaction needs to be performed, the connection is already open and the transaction goes through much more quickly.

mv.NET has some cost attached while MVSP is free. The connectivity mechanism described above is called the Session Manager. If you have a low-transaction environment, maybe with simple queries or updates performed once in a while, then you probably could go with MVSP. But if your system processes requests for a number of users, the cost of session management is actually lower than the cost of the DBMS licenses required to handle all of the connections.

As stated above, mv.NET actually uses MVSP as the underlying connection, while providing above that a huge variety of features that aren’t available anywhere else, let alone in MVSP. If you do not make use of any of those features, you may not need mv.NET. I used mv.NET in many sites in the past because other connection options for D3 and mvBase were inadequate. These days I would consider MVSP as a viable alternative.

If you already have mv.NET, you may consider replacing your connectivity code with the simpler MVSP interface. But – the cost to replace existing code may be more than the small mv.NET yearly licensing fees, and scaling down to MVSP might preclude other more sophisticated development later. As a simple example, you might find that you need to have multiple concurrent web service calls into your system, and eliminating mv.NET this year will actually cost you more next year if you need to consume more DBMS licenses with MVSP to handle that. Weigh these concerns well.

How does MVSP compare to QMClient or UO.NET?

Hey, TL is just another company with just another library. These minimal libraries all do pretty much the same thing for their specific target platforms: Connect to a server, login to an account, open a file, read/write an item, and execute a subroutine. Beyond that it’s not much more than syntactical differences and convenience functions. None of these have session pooling or anything near comparison with mv.NET.

If the MVSP client is Java or .NET, how do we connect with PHP or another language?

Create a Java or .NET class library (jar or dll) that exposes an API that you define. Research how to execute such functions from your language of choice – for example, google for “call Java method from PHP”. You’ll find there are “bridge” mechanisms to do this.

What would Tony use?

If the task is to create something simple, with access from client code on the localhost or over the local network, then I would consider MVSP. As soon as someone says there may be more simultaneous connections, I’d immediately reconsider in favor of mv.NET. I have already created a wrapper library where I can call to any DBMS using whatever connectivity is appropriate – mv.NET, MVSP, UO.NET, QMClient.NET, or even SSH. Switching connectivity is as easy as changing a config file – and then I can focus on important stuff like applications and data, rather than connectivity.

If the work all needs to be done on a local Linux system, I’d probably use MVSP/Java.

Having said all that – since each situation is different I can’t really say here what I would use. That’s really my whole point here. We don’t choose solutions before we understand the problem. MVSP is just another tool in the kit. Learn its strengths and weaknesses so that you can make your own choices about where it fits or not. I’ll be happy to help if I can.

I won’t go further on this except to say that I wrote a “Using MVSP for .NET” guide a while back that I still need to finish up. If you’re just learning MVSP and it’s a hassle, please let me know and I might be able to help. I’ve also written a MVSP Extension Library (MEL), which makes functionality available in MVSP that TigerLogic didn’t build in. This is one of the cool things about .NET, that we can extend software to provide features that were not included by the original developers. If I can find some time I’ll publish a list of MEL features. Hey, maybe someone might even buy it! 😉