Re: mvDesigner

"Peter McMurray" wrote:
Does anybody use mvDesigner? If so is it any good relative to other
offerings such as Visage, DesignBais, Zen etc.
Peter McMurray

mvDesigner (aka mvDisaster) was a great idea which as usual was
mis-implemented by RD. It was built on Omnis Studio which has its own
pros and cons:

Pros
- Cross-OS development (Windows/Linux/Mac)
- Cross-OS deployment
- Thick and Thin client
- VERY object-oriented, elegant, rich libraries
- Passionate developer base - like MV community but geeky
Cons
- Expensive development/deployment
- VERY complex, way too much for the typical MV crowd
- Owned by RD (need I say more?)
- Questionable future compared to competition

With Kylix/Delphi being one of its only competitors, Omnis Studio has
been a fairly unique offering for many years, and RD has squandered
all opportunities to make it a mainstream standard. However, today
people use Flex/ActionScript, Flash, and now Silverlight/Moonlight
built with XAML. These tools are also cross-platform - and all of it
is free, though of course most sophisticated IDE's have a cost. Omnis
Studio can't compete with mainstream tools that do relatively the same
thing for free.

mvDesigner was Omnis Studio with some built-in help to connect into D3
using FlashCONNECT as a pipe. For all other databases Omnis uses a
Data Access Module (DAM) and I have no idea why no attempt was ever
made to create MVDAMs for all MV platforms. Today you could simply
use Omnis Studio all by itself and connect to any MV back-end using
mv.NET. However, that would still require a Windows web server
somewhere in the topology (easily done with a vmWare virtual).

My conclusion of mvDesigner was that it was fine for the very first
demo but if you wanted to do anything more complex you really needed
to learn Omnis script. Well, if you know Omnis script then you don't
need the mvDesigner crutch. So anyone who is getting this product
needs to make the decision to commit to Omnis Studio and all of its
complexity first, then just use whatever plug is available for MV.
The "easy to use" mvDesigner concept was really bait n switch - for
real development there was nothing easy about it. Again however,
there are a lot of Omnis developers out there - so if someone was
willing to make the leap, years ago it wasn't a bad leap to make.
Today however, I think Omnis is really threatened by modern mainstream
competition.

Comparing mvDesigner to other offerings in the same class:

To DesignBais: mvDesigner is WAY more complex and more expensive.
DesignBais was written by MV people for MV people and is entirely used
with BASIC, no scripting or object-oriented programming required.
However, DesignBais is for browser-only deployment.

To Visage - Ibid for the most part. Ross?

To Nucleus - This is a tri-mode deployment product where development
of a single UI (as I understand it) can be deployed as a character UI,
thick client And thin-client/browser. I'm not sure if the thin client
is cross-OS. While impressive, Nucleus is similar to Omnis in that
it's sort of rocket science in complexity, and I'm afraid it doesn't
have strong enough backing to get more acceptance in this market.

To Zen - mvDesigner is D3/mvBase only and Zen is Caché only. Zen is
thin-client/browser only like the tools above. Similarly however,
like mvDesigner relies on Omnis Script, Zen relies on Caché scripting,
with Caché Object Script (COS) or MVBASIC to provide complexity. Zen
is free with Caché, and while I know it will be well supported, it's
not as mature as Omnis Studio and I don't believe it will ever have as
much functionality.

To OpenInsight (OpenInsight/Linux) - If you're going to put a
cross-platform front-end on your app, you could consider OI/OIL.
However, this only works (so far?) for the Revelation/OI DBMS platform
and now for U2. There is no DAM for other MV environments. ( Mike, I
know what you're thinking... ;) )

To ATGUI - This is sort of the AccuTerm equivalent but only for thick
client and only for Windows. (BTW, keep your eyes open for Symbion
which is an intelligent front-end development utility built over ATGUI
and is very hot.)

To Visual Studio - When RD was developing mvDesigner I suggested that
it would be better to integrate Visual Studio with easy to use
components that integrated with the MV back end. My view was that VS
was a mainstream development platform, thick and thin, and that it
would be much easier to learn VB and find VS developers than to learn
Omnis Script. Being motivated to sell Omnis, RD forged ahead with
mvDisaster. When that didn't work (told ya...) they made agreements
to sell and support PDP.NET - ahem, built into Visual Studio.
Unfortunately they only supported D3/mvBase and U2, and didn't take
the product in the right direction. So mv.NET came along, learned
from PDP mistakes, and everyone I know who was using PDP is now using
mv.NET. Like Omnis Studio, .NET thin clients are cross-platform, but
with .NET there is no client-side installable component. With the
success of Ajax these days we can get the same sort of very rich
client experience from .NET that we get from the Omnis web client.
And with Silverlight/Moonlight which use XAML and .NET coding (C#,
VB.NET, or any of over 30 other languages) and a thin browser plugin
(just like Omnis) we'll now be able to use the same code for thick and
thin cross-platform deployment.

To NetBeans/Eclipse - Rather than locking into a proprietary library
with a questionable future like Omnis script you should consider more
mainstream development environments for Java. But the communications
interface is now the responsibility of the developer. You can get
into D3 and mvBase with jD3 or the FlashConnect Java interface, into
U2 with UOJ, and other platforms will have other solutions.

The "supposed" advantage of mvDesigner was the vendor-supported
interface between client and server. As we've seen, the vendor didn't
do a very good job of supporting that, so here we are eight years
later and people are still looking for solutions. I've been saying
for a long time that we have the tools available in the market and
that we shouldn't rely on the DBMS vendors to provide end-to-end
solutions. mvDesigner and PDP.NET are perfect examples of why.

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and DesignBais worldwide,
and provides related development and training services


.

Relevant Pages

  • Re: RD Marketing
    ... >> now marketing vertical applications that are built over their ... It requires someone to learn Omnis ... and by the time someone knows Omnis scripting they realize ... >> that they don't need mvDesigner. ...
    (comp.databases.pick)
  • Re: RD Marketing
    ... It requires someone to learn Omnis ... and by the time someone knows Omnis scripting they realize ... that they don't need mvDesigner. ... idea of Omnis was that it was yet another single-source tool in a world ...
    (comp.databases.pick)
  • Re: DesignBais - Impressive
    ... some competition to MvDesigner? ... Raining Data has no specific position regarding DesignBais. ... Omnis Studio is great software but it's EXTREMELY complex. ... the Pick market who could use mvDesigner but anyone in our market can ...
    (comp.databases.pick)
  • Re: Where does Access do its WRITES?
    ... previously worked with Omnis Studio (and Omnis as far back as V3.24 in ... converting an application from the pick database system (raining data d3) to ...
    (microsoft.public.access.gettingstarted)
  • Re: Where does Access do its WRITES?
    ... previously worked with Omnis Studio (and Omnis as far back as V3.24 in ... converting an application from the pick database system (raining data d3) to ...
    (microsoft.public.access.gettingstarted)