Hi Tony
Thank you very much for this great overview - I have no idea how you get
time to cover so many products.
Peter McMurray
"Tony Gravagno" <address.is.in.posts@[EMAIL PROTECTED]
> wrote in
message news:l8nd145oqmjlrukprr8p3aoae6kvsj5qmh@[EMAIL PROTECTED]
> "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 op****tunities 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 sup****ted, 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 sup****t PDP.NET - ahem, built into Visual Studio.
> Unfortunately they only sup****ted 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-sup****ted
> interface between client and server. As we've seen, the vendor didn't
> do a very good job of sup****ting 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@[EMAIL PROTECTED]
remove.pleaseNebula-RnD.com
> Nebula R&D sells mv.NET and DesignBais worldwide,
> and provides related development and training services
>
>
|
