Re: Cost of ownership: MV vs. SQL Server


Tony Gravagno wrote:
> "dawn" <dawnwolthuis@xxxxxxxxx> wrote:
> >Tony Gravagno wrote:
> >You can be OS-independent, language independent, database independent,
> >app server independent, etc, but you cannot be all of those at once.
> >Even if you could, there would be no cost-benefit analysis that would
> >suggest you should.
>
> And this is what confuses me about some of these discussions. I
> mention that .NET seems to satisfy all of the business requirements
> that people put on the table, and then we see "but it doesn't work
> with Mac or the Linux desktop". You're right Dawn, we can't please
> everyone, nor should we try.

Agreed. I work with vertical industries that have non-Windows desktops
(both Macs & Linux), so my criteria are different from yours. However,
now with so many software apps geared to customers, suppliers, etc, a
company cannot control the user equipment. You don't want to limit
your online sales to those with Windows running IE because you used a
..NET solution for the client, right?

> There are basic business needs in this
> world and the lines have to be drawn somewhere. There are so many
> isses to wrestle with in this IT game: business concerns of stability
> and corporate dedication, quality, ease of development, ability to
> easily find qualified developers, marketing benefits of using one
> technology over the other, etc. Weighing all of these concerns over a
> long period of time, I keep coming back to .NET as being a good answer
> to the problems facing most businesses in terms of "what technology
> should I adopt?" This is always a moving target too but we've seen
> .NET start out with the beta, v1.0, v1.1, and now v2.0. There is a
> consistent trend toward quality and improvement, as it still addresses
> the major business concerns. That can't be said for other
> technologies.
>
>
> >So, you need to decide to partner in one or more of these areas and
> >help your partner be successful to protect your investment.
>
> This dove-tails precisely with my above comments. You need to get on
> the train somewhere and just start moving (another consistent theme of
> mine here). You can't wait for the perfect solution for all
> platforms, you need to just make the decision and get going. There
> will never be an ideal starting point. There will never be a perfect
> partner.

Agreed. And I'm not saying I don't have solutions in the Java world.
There are hundreds of college campuses using UniData with UniObjects
for Java, servlets, and browser front-ends with students registering
online through a browser. I'm not sitting around wondering if there is
a solution, but I do think there could be a solution I like better. It
is not as lean & mean a solution as I would like.

> There will never be a magic bullet to convert a greenscreen
> app to a marketable GUI with no code changes. MV people have to stop
> waiting for perfection because the market is dying as they do so. In
> a way I'm partnering with Microsoft as you say, but as a technologist
> I always have my eyes open for what else is going on and if I see
> something better I'll put some eggs in that basket too.

Yes, that is where I am, except that you seem happier with your
solution and I suspect that the .NET apporach with mv.NET is ahead of
where I am with Java solutions in ease of development, for example.
So, if you do not anticipate external (to your company) end-users of
your software and you are all Windows, .NET sounds like a good
approach.

> But I can't
> sit here and never hop on any train (pardon the metaphor) because I
> don't like the color or smoke from the ones that go by - because
> they're moving and if we don't hop into "some" vehicle, we are not.
> People are buying MS solutions regardless of all of the rhetoric about
> whether MS is satanic or that their modeling isn't astheticly pleasing
> - such things interfere with the basic reason of why we're all here,
> making money, paying bills, retiring comfortably, maybe leaving
> something for posterity.

Yup. Some folks are solidly Microsoft and others are not. For those
who can choose, if they can live with the constraints and MS
partnership, they might find it a course of least resistance to go with
..NET, from what I am hearing from you and others.

> >If you opt for MS as a significsnt partner, then you end up with a
> >powerful partner who you don't need to nurse along at this point, but
> >you do have a greater risk of having all of your eggs in one basket
> >than with some other approaches. I am looking to see if that problem
> >becomes lessened in the future.
>
> It's wise to look but for most people here, they're waiting for people
> like us to look and leap and fail so that they can say "I'm glad I
> didn't do that". Life is about making leaps and sometimes business is
> even more so.
>
> >> Coming back to Crystal Reports, this means you can setup an MV
> >> datasource for your CR reports using Pick Access/Recall or even using
> >> BASIC to generate a select list and return data, not just SQL via
> >> ODBC.
> >
> >I would love to see that. It would seem there are assumptions even in
> >the reporting tool UI that anticipate "normalized" data,
> Remember from my prior post that .NET bubbles everything down to a
> dataset. A dataset contains tables which have data and schema and
> some RI. The source of the data, schema, etc can be anything, it
> doesn't need to be relational, it can be .NET. The trick is to get MV
> data into that neutral normalized dataset format from which all of
> these other products can use the data and do what they do. mv.NET
> accomplishes this elegantly. As far as seeing it, when I get some
> time I'll work out a demo - it's in my task list.
>
> >although hopefully this is changing with xml data sources coming
> >into play. I
> >haven't seen xml-based reporting tools yet, however, other than raw
> >XQuery. I have a tool loaded, but just haven't had the time & priority
> >on it.
>
> .NET is heavily based on XML at the core. It uses XML to move data
> between sources. The developer and user never need to see the XML in
> play, but you can tie into the XML if your target is to work with XML
> - it's sort of the difference between driving a car because you need
> to go places or driving because you're a car mechanic and you need to
> listen for clicking.
>
>
> >In case it isn't clear, I am missing everything related to .NET.
>
> No prob - I've lost any Java chops that I had too. We can lean on
> each other.
>
> [snip notes on Yukon=SS2005, Longhorn=Vista, WinFS, etc, I'm not
> qualified to discuss these beta products]
>
> >> The
> >> application is initially deployed through a browser. After that, when
> >> the thick-client app is run it checks for updates from the remote
> >> server.
> >
> >That sounds something like Java Web Start, perhaps?
>
> Exactly. DLL's and EXE's instead of CABs. But before anyone starts
> posturing about how MS is so far behind Java I'll note that there
> probably isn't a soul in this forum who has actually written an app
> that uses Java Web Start,

I have, but for training purposes and not a production app.

> and probably less than 5 who use an app that
> does.

and I do -- I have used a couple, including ARGO UML diagramming tool.
It isn't great, but it's free.

> In all of the time that Sun has been touting Java it still has
> not captured the hearts of the common user (us) and that is what
> leaves room for MS and .NET and related and better solutions (Mono,
> etc).

I absolutely agree.

> I like and appreciate Java, but no one has ever offered to pay
> me for a Java solution despite the fact that I've written demos and
> did get heavily involved with EJB and JDBC and Swing, etc for some
> period of time. As good as Java is, it has its faults which .NET
> seems to have solved.

agreed.

> If Java was ever going to "take off" it had its
> chance, since the market didn't go Java-happy, I need to find
> something that they'll like better.

Google, among others, does use Java behind its applications, as well as
python and php IIRC.

> There aren't that many
> industry-shaking development paradigms out there to choose from...
>
>
> >> Updates are made automatically and the end-user always has
> >> the latest version. There are no deployment issues.
> >
> >Is this the case for Macs? Linux desktops? Phones? PDAs? Other
> >non-MS client environments?
>
> No, but again, I'm pretty much focused on the needs of the MV market,
> and this market has never expressed a real need for Mac, Linux
> desktop, phones, PDAs, or other client environments.

You are fortunate if you work only with customers fine with all MS all
the time.

> Hey, you folks
> know I've tried to drum up interest over the years to get people to
> ask about all of these things (well, OK, not Mac). This market is
> simply MS-client centric despite all of the rhetoric.
>
> Thinking about this I'll note that Mono (.NET for *nix and other
> platforms) does not seem to have zero-touch deployment down yet but as
> with everything else they probably will at some point, so yes, keep an
> eye open for .NET-based zero-touch deployment for your Mac and Linux
> desktops...

I will.

> [snip model-view-controller fun]
>
>
> >> IE isn't required for this sort of UI but I think it's preferred.
> >
> >It is OK as one browser, but not prefered by Mac clients, for example.
> >On Win XP I use FireFox more than IE. IE isn't available for all
> >platforms, but one web browser or another is.
>
> I meant that for a rich WindowsForms-like UI, IE preferred by
> developers of these sophisticated controls because it has the hooks to
> support it, where tool developers need to play tricks to make other
> browsers do the same things.

That was the case, but now it is IE that seems to be pulling up the
rear in the standards department. But the point in either case is that
you don't get all browsers as possible clients for your software for
free -- there is a cost to AJAX development, for example.

> However, some UI component developers have successfully ported very
> attractive components to a variety of cross-platform/cross-release
> browsers. The Telerik r.a.d. components are one such example, and
> here's a table of the browsers they support:
> http://tinyurl.com/bbpda
>
> >> Some people will still scoff at the idea of
> >> using IE at all. In this case, this or any other browser is less of a
> >> web surfing tool and more of an application container - it's not a UI
> >> but a deployment mechanism. Used in that context even the most
> >> anti-IE people in the crowd don't have much to room to complain.
> >
> >I don't quite follow this point. I see the browser as a client
> >run-time container and the web server as the deployment mechanism for a
> >particular app.
>
> (Subtle point here, I may be repetitive...)
> Most people see "the browser" as their window to the Internet. It
> allows you to "browse" The Web, to "surf" the net to a wide assortment
> of disparate places. When we're building applications that are
> targeted to the browser, we don't want our users to "browse", we want
> them to stay in one place and use the tools that we've provided to
> perform their business operations. In this sense I see the browser as
> merely a container to hold components for a specific business
> function. And in this sense there is no such thing as "preferred"
> browser because the user isn't browsing. If the user is going to
> browse, they can use NS or Safari or whatever, but if they are going
> to use my app they are going to use the container in which I wrapped
> my app.

I think we are working with different users. To get into my head on
this, perhaps you could think in terms of an asp solution or a customer
buying from a web store, or a student registering for classes where you
have no control over the desktop environment of the user and they might
not do business with you if you don't work with their browser.

> I can code my app to remove all of the "chrome" and skinning
> that is usually present in a browser, and just show the main forms
> without exposing the container. In this case I'm getting the benefit
> of the point and click medium, the IE DOM and everything it supports,
> network connectivity, etc - and there should be no argument from the
> user about "how" I achieve the resulting application.
>
> >> >However, issues for the MV community include that there are no standard
> >> >libraries (in java, php, etc) for connectivity. It is a shame that
> >> >with so much standardization in the base product, the MV vendors could
> >> >not provide any standardization for client-server connectivity.
> >> >cheers! --dawn
> >>
> >> [ad alert]
> >> Dawn, I think we (Pickies) have a new solution. I highly recommend
> >> investigation of mv.NET and I'll be happy to help with that process.
> >
> >At this point I have been working with open source and other similarly
> >low-cost solutions. I have knowledge of Java, JavaScript, XHTML, CSS,
> >PHP, XML and other TLAs but I'm not yet satisfied, while it sounds like
> >you are.
>
> I don't know if "satisfied" it the real feeling there. I need my
> business to make money, people don't buy solutions using the solutions
> you've mentioned (at least not from me anyway), so I need to find
> tools that people will buy from me, pay me to use, etc. This is more
> a decision of survival than satisfaction.

I think you are right. I'm going the open source route and will need
to think about dollars sometime before I starve.

> >What is going for me on this side of the house is that I
> >think google has some of the best minds in the industry and most
> >satisfying applications. In the google vs Microsoft wars now and to
> >come, I'm happy at this point to align with google's application
> >development strategies unless or until I decide it just isn't going to
> >work for me. But if someday I decide that .NET is a better direction or
> >needs to be part of a solution, you know you'll hear from me :-)
>
> Hmm, Google is providing server-based tools and allow developers to
> access their tools via Web Services.

and via a browser UI, as in the case with gmail or google maps.

> They are a
> technology-independent service provider. They do not provide the
> underlying technologies which developers need to use to access their
> services. They intelligently assemble components to do a job, but
> they themselves are not low-level component developers. For that we
> have Microsoft, Sun, and people that provide SOAP, XML-RPC and other
> specs for the middle-tier. It's not that Google has a "better"
> solution than .NET. .NET is an architecture which allows you to use
> Google "better" for the apps you develop.

We are talking about different things. I'm saying that google is
writing software that I like and I can use similar tools to write
similar software.

> I see these things as
> playing at a different tier.
>
> Related: people always lump Java and .NET in the same tier. .NET is
> an implementation of a spec, for which there are other implementations
> possible. J2EE is a spec, and Java is both a language as well as the
> only implementation of that spec - Java and J2EE are virtually
> synonymous and inseparable. There are over 30 languages supporting
> the .NET Framework, and with the Mono project we see that there are
> alternative implementations of the spec as well. Like the sound of
> scratching a blackboard, it pains me to see these technologies lumped
> together into the same conversations as though they're all the same
> thing or somehow comparable. Like I said Dawn, we can lean on each
> other with these things.

I think of .NET and the JVM as similar -- both of them as virtual
machines. I know that .NET is used to mean other things too, but that
is all I have kept in my brain. In fact, the jvm and .NET might both
stem from p-code machines (I know the Java JVM is derived from the
p-machine as PICK is)

> >> This toolkit is cross-platform for D3, jBASE, mvBASE, Power95,
> >> Reality, Universe, Unidata, and Univision. They may also add support
> >> for mvEnterprise and Revelation OpenInsight. I think they support any
> >> OS platform that these DBMS products run on, and they pretty much
> >> support any available release of these products as well. That's about
> >> as "standard" as any connectivity tool is going to get in our market.
> >> mv.NET comes from BlueFinity International which is a "sister company"
> >> to jBASE. The corporate backing for the product is high and support
> >> is excellent and personal. I have nothing but praise for the product
> >> and the people who make it available. I know many of our colleagues
> >> are now adopting mv.NET, perhaps some of them will make their own
> >> statements here.
> >
> >Maybe I should work with them to imitate this approach on the non-.NET
> >side of the house? If I understood what .NET provides, then perhaps I
> >would understand what it would take to do something similar for Java,
> >PHP, and other environments.
>
> The only thing I think you could hope to achieve is a library with the
> same interfaces but a completely different implementation underneath.
> The syntax for C# is very close to Java so it would just be an
> exercise to support all of the same functions.
>
> I would question the merit of porting mv.NET syntax to Java directly,
> however. UOJ has been out for a long time but we don't see a lot of
> U2/Pickies flocking to Java or UOJ.

I see a good share. Both the Datatel VAR and Entrinsik Informer use
UOJ, for example.

> I don't think that has to do with
> syntax but with the fundamental reasoning behind adopting Java. If
> you determine that a number of Java developers would adopt MV with the
> availability of a feature-rich and cross-platform Java API, then all
> you need to do is get the mv.NET docs and start drawing up the
> interfaces. I can guarantee that this won't be trivial.

I can only handle trivial right now, so nevermind ;-)

> One of the beauties of .NET is that all they had to do was write the
> code once (in C#), and for the most part mv.NET can be used by most of
> the .NET-compliant languages out there, VB.NET, COBOL.NET, etc - even
> J# for what it's worth, which _is_ essentially Java, so you could use
> mv.NET now if you want Dawn.

I am aware of that, but since I glaze over when I see the word .NET
(unless typed by you, Tony), I'm just not interested right now. Maybe
someday.

> In fact, I'd maintain/suggest that you
> could write your Java code using mv.NET and J#, and if you later
> determine that there's a real financial incentive to port it to *nix
> or Mac then you can do so. Your code CAN be used for clients with
> phones, PDAs, tablet PCs, and in web sites, on any OS, and you can
> access any MV or relational server, regardless of platform - you just
> can't use Mac or Linux as a middle-tier server - but who sees that
> anyway?!

Ah -- I have another point to make and it is a good one for me. I use
an ISP. My web server's server platform is Apache on linux. I can
deploy php or (they tell me soon) tomcat/java with my isp. They also
tell me that soon enough I'll be able to install my own database or I
can pay for their support of MySQL. I could also pay to rehost on a
Windows box, but then I could not use tomcat.

, you'll need a Windows box in the mix somewhere. This is
> hardly unacceptable.

It might be for small guys like me who don't host their own servers.
That is one reason that LAMP (linux, apache, MySQL, PHP) has taken off
-- ISP's can set it up for all of their customers to use.

>
> >> In what way is it a standard MV product? In short:
> >> - A single library allows manipulation of accounts, files, and all
> >> dynamic array structures, plus execution of BASIC code on any server.
> >> That's one library for all MV platforms.
> >> - The library includes many utility functions and function overloads
> >> that make it more familiar and friendly for MV developers.
> >> - Grids, listboxes, and other components are easily bound to MV data.
> >> - Indexes and transactions are supported, based on whatever
> >> functionality is available from the DBMS.
> >
> >Impressive. Unfortunately, if it requires .NET to operate, then it is
> >anything but "standard" in my world, but I should take a look sometime
> >anyway.
>
> Based on the above maybe you'll have a different view. You get the
> language that you want and the platforms you want. Consider .NET a
> component among many in your toolkit. Maybe the notion of going
> entirely to one side or the other needs re-thinking (for both of us).

I'm good with the Jack Sprat scenario for now -- no time to learn it
all.

> >> For .NET developers who aren't familiar with MV at all, the ADO.NET
> >> integration also makes MV data available using syntax that's familiar
> >> to them, and using any language they want, including most of those
> >> listed here: http://www.dotnetpowered.com/languages.aspx
> >> [/ad]
> >>
> >> There are no universal language access solutions across DBMS
> >> platforms. SQL syntax and other nuances vary in many annoying ways
> >> for relational DB platforms, much like MV products. So
> >> "standardization" shouldn't be put on the table as something that is
> >> available in the SQL world but not in ours
> >
> >I have been intimate with ODBC against multiple DBMS's and you are
> >definitely right. In fact, MV languages are much more standard across
> >products than is SQL across RDBMS's, so it is the client/server (or
> >however you want to say it) standard that is lacking. If mv.NET could
> >be expanded to be useful outside of .NET ...
>
> I think we're at the point where a few hours in a pow-wow would
> enlighten both of us on some of this. Let's look for opportunities
> off-line.

Sounds good.

> In parting, I'll cite your quote to Kevin in another recent post:
> > a software company that functions as a asp
> > and/or one that has a significant installed base would likely have no
> > problem. It would not matter what technology was underlying
> > salesforce.com, for example.
>
> So does it really matter if it's .NET?

I'll claim enough ignorance not to know the answer to that question.
Cheers! --dawn
> >>
> >> Inquiries about mv.NET are welcome.
> >> TG@ removethisNebula-RnD .com

.

Relevant Pages

  • Re: sick of Linux bias
    ... > In my personal experience *nix tends to be deployed in either ... Specific business applications, that is, as ... that are not using ms office as a business app. ... Linux in the enterprise market is a viable solution. ...
    (comp.security.firewalls)
  • Re: sick of Linux bias
    ... > In my personal experience *nix tends to be deployed in either ... Specific business applications, that is, as ... that are not using ms office as a business app. ... Linux in the enterprise market is a viable solution. ...
    (alt.computer.security)
  • Which Guest OS to use on VPC 6.1.1 (or in future VPC 7.0)
    ... I am trying to decide which guest OS to run inside of my Virtual PC ... I don't need to run a GUI in that Guest OS since the Mac can ... The kink in the plan is that the app is a server app that requires 1GB ... Linux or MSFT Windows ...
    (microsoft.public.mac.virtualpc)
  • Re: How would you steer Delphi if you were Nick?
    ... If you are a small company and user expect you to support them 24hrs a day it makes no difference if it is Linux or Windows. ... Depends on if your application is a core business tool or not. ... (shell script used to install Kylix) ... Win Me and below do not run every app that can run on NT. ...
    (borland.public.delphi.non-technical)
  • Re: Linux: open file with proper app
    ... >> large part because I'm not familiar with the workings of various window ... beyond (since our app no longer supports anything earlier) and Mac OS X, ... command you've provided works great on my Linux box, ...
    (comp.lang.java.gui)