Connecting with MV

What about products like DesignBais, Viságe, WebWizard, or FlashCONNECT?

I’ve written a lot about these products so I won’t expand on them too much except to put them in perspective. These tools wrap the underlying communications so that you don’t have to. They use sockets, Telnet, UniObjects, QMClient, or even mv.NET internally, but you as a developer never really need to be concerned with that tier. As the vendor APIs are focused on simple connectivity, these products focus on providing developer tools way above that layer. mv.NET also includes higher-level components, beyond basic connectivity.

Summary

Let’s say you have a character-based application and you want to port it to a browser. You may be tempted to write the entire end-to-end topology yourself. If you want a job done right, you have to do it yourself, eh? But given what you’ve read here, you really need to think about the challenges you’ll face at each tier. This is a major undertaking. If you’re building tools for resale to other developers then you will be accepting responsibility for effective management of the communications, so you need to get involved at that level. However, if you’re an application-level developer, employed with an end-user or selling your software, you have to ask yourself if you want to be in the business of supporting communications interfaces, or if you’d prefer to focus on selling and maintaining business application software. Time you spend figuring out delimiters and XML tags is time you’re not spending talking to prospects and clients.

While it’s an interesting challenge for any developer, this whole communications thing is a major diversion from the business that brought most people to MV development. Most MV developers start as accountants or doctors or with some other professional talent, and learn MV as a vehicle for providing applications in their field of specialty. Even if you can write code to support an entire web-based topology, I don’t think it’s a good idea to take the time to do so, as the list of things that need to be fixed and enhanced never ends.

For these reasons, I encourage developers to focus on what they know, do that well, and do whatever you can to stay focused on selling business software or otherwise keeping your end-users happy. Yes, that may mean you’ll need to pay other companies to do things that are outside of your own scope of expertise. If nothing else, look closely at the various offerings to understand exactly what they do, and use this to build your own TODO list of features you may need to support. Either you’ll get a well defined list of challenges that you’d like to undertake, or you may find that someone else actually does all of the things you need, and hopefully for a reasonable price.

All that said, if you want to get started "right now", I recommend you start with your favorite DBMS, identify the free API tools that are available, and start writing code with the idea that you’re prototyping, not writing a production solution. See how it goes, identify the strengths and weaknesses, and you’ll be much better able to figure out your next step once you have some experience behind you. Don’t hesitate to ask for help from our colleagues in forums. The people who have time and interest will answer your questions, and all of us are eager to learn from other people’s efforts.

I hope that helps someone…