HI
The pricing I mentioned is the current retail pricing from the
distributor. I looked it up as I was writing the email. As the
distributor D3 pricing has been adjusted for the current strong
dollar and they do push mv.Net I have presumed that there is no
reduction other than a developer discount that would be on a case by
case basis.

The 4gl comments seem to be confused. If one is using it to develop
the front end in Silverlight or whatever then it is a 4gl in much the
same way as Visage whereas SystemBuilder is not yet at that level -
although I have not seen the latest release which was last week if I
remember correctly.

I have no doubt that mv.Net is the most powerful offering around at
the moment and in my opinion the pooling is absolutely the most
important ingredient - and the most difficult part to write.

It is my understanding from the documentation that to use the pooling
one needs to set things up using the mv.Net schemas and develop the
front end in their style, I would be delighted to be proven wrong. I
am looking for a simple pooling pipe that accepts calls from a third
party web page and passes them direct to my internal subroutines. I
anticipate that this would be through a phantom or two set up by the
pooling system.
It is simply a stream control of data such as JSON.

Your book on MVSP would be a valuable addition to the D3
documentation.
Peter McMurray

Hi
Thankyou, I obviously misread the docs perhaps they need to be
revamped :-)
I shall watch the video.
By the way the $US is worth less than the $AU at the moment so I am
still unsure about price. In fact we have a local brouhaha at the
moment as many people have realised that it is cheaper and quicker to
order from Amazon than the local bookstore. Not only is the $AU
stronger there is no GST at 10% on orders under $1000.
Perhaps we can agree that mv.Net can be used as a 4GL but it has far
wider options. I must go back to those docs if I can find them.
If I have it right now the pooling is being managed at the level of
the Web server through a single Pick connect with more Pick Connects
being added as required. On the face of it a large sort will seize up
the pool so obviously there is something more to it. What is that
something?
Definitely interested as I have no desire to re-invent the wheel. I
think that Visage and DesignBais are excellent products, they just
don't fit my current wishes.
Peter McMurray

Excalibur21 <pgmcmurray (AT) gmail (DOT) com> wrote:

I neglected to provide a link:
nospamNebula-RnD.com/products/gallery.htm

As I said, a significant difference here is that the products that
claim to be 4GL completely manage the environment for you. You lose
the ability to control how the environment works but (arguably) save
some time by letting someone do that for you, for better or worse.

mv.NET will generate some code but it's entirely up to the developer
to make it do all the things that we expect production code to do.
That's not 4GL. Code generation does not equal 4GL. That's string
manipulation to create code by combining templates with
context-specific data. Saying mv.NET can be used as a 4GL sets the
wrong expectations because then people start looking for that "do it
all for me" feature set, and that's simply not what this product is
designed to do. In demos, the drag and drop capabilities look great,
and one can really create a basic GUI using those techniques. But in
practice, for the developer looking to create a complex RIA that
approximates the functionality of a CUI, you'll need to understand and
manipulate whatever code has been generated for you.

To summarize, if you're looking for a 4GL then you are probably hoping
to avoid getting a "Silverlight 4" book from Amazon. I'm saying this
is required. Such is not the case with a 4GL. What's in mv.NET is
really fantastic but understanding where it starts and stops will help
to set proper expectactions and avoid unnecessary disappointment.


That's correct with a slight modification. From the Gallery link
above, click the Topologies link and go to slide #7. You'll see there
that the session manager doesn't even need to be on the web server,
and in fact you can have multiple web servers all connecting into the
same session manager to broker connections to multiple DBMS platforms.
You can create some really complex environments here beyond "I just
need a web page".


The game here is to avoid having any session occupied for an
unreasonably long time. This is the challenge with ALL client/server
interfaces. You want all transactions to get in and get out as
quickly as possible. Technically you simply can't have a time
consuming process running because somewhere from the web server up
through the client browser there is going to be a timeout - the rule
of thumb is that if it takes more than 10 seconds your end-user is
going to get upset, and after 30 seconds chances are high that
something technically is going to interrupt the transaction. Just
don't go there.

If you suspect that any given transaction is going to take more than a
few seconds, the best approach is to use your time slice to tell the
server to do the task asynchronously, then leave it to do that task.
Come back later, perhaps with a polling mechanism to see if the task
is complete. You would do the same "in real life" even with a dumb
terminal: You start a report and then go away, coming back once in a
while to see if it's done. You don't sit there for an hour staring at
the screen until it's done, and you certainly wouldn't want to pay
someone to sit there and do nothing else but stare at the screen.

As a provider of consulting services I help developers to revise their
long running synchronous processes to work asynchronously.

These days Push technology is also making a comeback, where the server
can notify remote clients of status, rather than every client having
to Pull the status with frequent polling.


You're touching on an important point there. When people say to me "I
need a GUI", I'll ask a lot of questions, and I occasionaly refer them
to products other than mv.NET - even MVSP, QMClient, or UniObjects.
Remember, I'm the "right tool for the job" guy, not the "buy it from
me even if it doesn't fit, or stop bothering me" guy.) Our respected
colleagues think they're competing with mv.NET, and would almost
certainly not recommend mv.NET to a prospect. But these products
address completely different audiences. Selling mv.NET to someone who
is more oriented toward DesignBais or Viságe (or FlashCONNECT or
Coyote or Pavik or SB+ or Osmosis or ...) would be a dis-service, and
once DBI or Stamina realize that a prospect doesn't fit their profile
I would hope that they would feel comfortable referring the prospect
to Nebula R&D for mv.NET. Unlike others in this market, my "agenda"
isn't to sell products, but to help people move forward with MV
development. I don't care how they do it. I just hope I can pay my
bills somewhere along the line while helping others to get where they
want to go.

(Unusually civil discussion here Peter, we need to start slinging some
hash somewhere...)

Regards,
T

On Apr 9, 7:34*am, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid> wrote:
<snip>
I can not speak for the the other products, but Visage IS extensible.
We have VAR's that access and leverage 3rd party components and web
services, and the environment allows developers to encapsulate their
own reusable components. Whilst most people tend to use the full
environment, it is possible to simply use the Visage plumbing and
write code in any language or environment that supports COM+ or HTTP,
even .NET, though this isn't where we pitch the product.

<snip> *Where the mv.NET Silverlight integration differs
You are right in terms of Visage --> you don't HAVE to understand what
goes on under the hood in order to use the product, nor do you need to
learn, understand & master multiple new environments & languages,
but ,,,

<snip> *With Vis ge and DesignBais, all of the internals
this statement is wrong with respect to Visage - we don't discourange
people from understanding what is going on, though just as with mv.NET
we don't necessarily document in detail how our pooling works, or how
the data abstraction (schemas?) operates. However, we have always
fully supported & embraced the use of javaScript, IF a developer
wanted/needed to "play around" and do something that wasn't available
or supported "out of the box"

You always seem to lumber us with the limitations you experienced with
another product, but in reality have never even taken a Visage test
drive (& pronably never will :-)

Hi
Most informative slides and videos the mv.Net people should replace
the useless flyers with these,
Thank you
Peter McMurray