Re: compilers
- From: "Glen B" <dfdfg@xxxxxxxxxxx>
- Date: Tue, 28 Feb 2006 22:22:05 -0500
Tony Said:
I appreciate the thoughts my friend, but my bottom line is that I
can't get involved with software these days without some fiscal
justification. As a technology guy it pains me to say that, and I'd
really like to take advantage of the benefits we can all derive from
producing and consuming OSS. But unlike you, I'm not getting paid
while doing pure research. Given the chicken and egg nature of supply
and demand, I can't make the investment of time in yet another DBMS
unless I see a ready market with obvious needs that I think I can
I don't get paid to do research, post information, or write code for
OpenQM. I do it on my free time, which isn't really that often now. I do
what I can, when I can. I took down MV Developer Central for that reason(and
because it blew up). I just don't have enough free time to take care of it
all and work a full(over)-time job writing in-house code. Participating in
projects like this doesn't really benefit me at all, since I really can't
migrate the company's plethera of code and interfaces to OpenQM. When I see
something with great potential, I just can't help but to get involved in any
manner that I'm able to. :P
satisfy. I know I could provide for-fee products and services for the
for-fee QM, but no one has ever called to ask me about QM, and I don't
know any VARs or end-users who have ported to QM. Referring back to
my note about Northgate/Reality, LadyBridge and other VARs aren't
building any bridges between the demand-side end-user market and the
supply-side providers of products and services, so people like me
don't even have access to the for-fee QM community who might be
looking for products or services to enhance their experience. People
who do discuss QM/OpenQM seem to emphasize the free beer notion of
OSS. When the market is mature enough to understand that even free
software has associated costs, then I might start warming up to it.
If someone made a commitment to development with DesignBais or mv.NET
if/when these products are available for QM, I'd definitely start the
familiarization process.
We'll see. An XML project(including integral SOA) is in the planning stages
right now. If/When development moves along, an MS.NET interface will be
possible even though I won't have time to write it myself.
Yes, I still have it on my system. I'll explain my "100% managed"
statement and others. .NET _is_ .NET for a number of reasons. It
addresses a number of problems that have plagued developers for years.
QM.NET is a page full of code like this:
[DllImport("QMClient.dll")]
public static extern void QMCall(
string subrName, short argCount,
params string[] args);
This statement defines a wrapper to call a non-.NET DLL (QMClient.dll
in this case). That's all there is to it. Anyone could have put
together this entire interface in a few minutes - there's no skill in
creating a wrapper. Giving it a name was, IMO, a bit disingenuous. A
wrapper allows .NET code to transparently use non-.NET code as though
it were written in .NET, allows us to re-use older code without
re-writes, etc.. The problem is that if the underlying code blows up
for whatever reason, it will take out the .NET code along with it.
One of the major advantages of .NET is the ability to prevent major
blowups like this, or at least to control how such things are
resolved. So by wrapping a COM DLL we pretty much lose one of the
basic benefits of using .NET.
The can be said for any interface that isn't written directly into the
core of the main application(MV DBMS). Just like socket connectivity is
nothing like a common C library, a .NET application interface can either be
remote XML object based or directly integrated using the .NET programming
specs. Anything else is .NET capable, not .NET enabled. Am I wrong?
I'm really not a purist on this, I use COM Interop as it's required,
and I trust QMClient.DLL isn't going to blow up. Since people aren't
familiar with the benefits of .NET, if a program does blow up on them,
well, they expect that sort of thing from software anyway. I'm more
vocal about this only because I want people to understand WHY I use
.NET. But I'd use the QM.NET wrapper and I'd encourage others to do
so as well, but only with the caveat that something better "should" be
used if/when available. I have the same issue with UniObjects.NET
which AFAIK is just a COM Interop layer over the old UniObjects DLL.
You aren't getting all of the benefits of .NET, and certainly none of
the benefits of a product like mv.NET, but you are getting something
fast and free which is what most Pick people tend to settle on anyway.
I haven't played with mv.NET so I have no clue how much of the architecture
is in MV BASIC. Having said that, with the assumption that much of the core
HAS to be in BASIC for platform compatbility;
How can mv.NET be a.NET "enabled" product, if it's not a direct part of the
MV DBMS core? If mv.NET is written in BASIC, then what's the difference
between that and using a direct core access component or library like
QMClient or UniObjects? I'm still trying to figure out where you draw the
line between something that will work with .NET and something this _is_
..NET.
Glen
.
- Follow-Ups:
- Re: compilers
- From: Simon Verona
- Re: compilers
- Prev by Date: Re: Visage, DesignBAIS...
- Next by Date: Re: OpenQM vs. Everything Else
- Previous by thread: Re: Visage, DesignBAIS...
- Next by thread: Re: compilers
- Index(es):
Relevant Pages
|
Loading
