Re: OpenQM doco in Wiki
- From: "BobJ" <bob@xxxxxxxxxxxx>
- Date: Fri, 21 Jul 2006 04:13:22 -0400
The 'direct access' is one of the real strong points of old fashioned
serial-like connections. You can validate every key stroke without
noticeable delay. If one of the clients is very remote and uses a slow
modem or a satellite broad band then there is a very distinct and
distasteful delay between "send" and seeing something happen. So off
loading the validation has real value even if there is an occasional second
burp because the server has been updated while the client was "away".
My little hobby project - what else is an old man to do - has a network of
four computers as follows:
Ka band satellite - The Server is here and there is latency. The server
will move to the DSL when the software is stable.
Sprint DSL.
Adelphia Cable Broad Band. This one is in a very small town near Lake
Okeechobee, Fl. and suffers frequent service interruptions.
Roving laptop that connects any way it can.
The current solution is to download the input programs and the basis for
validation when the remote computer first connects. Obviously there is a
little bit of configuration management taking place here so downloads aren't
done if they are not needed. If the remote computer sends something that is
not valid then the download is repeated on the assumption that the two
systems are merely out of synch. Works, but strange things can happen and it
takes a lot of logic to prevent the last gasp effort, which is reboot and
reconnect.
This is running albeit in Beta on jBase, Universe, and QM. The server
can be either jBase or Universe but hasn't been tested with QM yet.
Probably works there as well because QM works very well and may be the final
choice. FWIW I tried Cache` but it was too big a shift in thinking to
permit a good test without a lot of effort so I dropped it without
prejudice.
Any thoughts will be appreciated..
BobJ
"Peter McMurray" <excalibur21@xxxxxxxxxxx> wrote in message
news:6p%vg.8452$tE5.1555@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi
I agree about reducing work but what sort of work is anyone needing to do
that is not covered by the 4gl itself. I would definitely disagree about
business rules being on the client. Database look-ups are surely covered
in any 4gl by table loading. I remember that you had an excellent Law &
Order application, surely the felon photographs should be on the server
even though they do represent a load. As for the wider internet ie those
outside the internal structure of the company then nothing should be on
the clent.
Am I answering my own question? One must differentiate between internal
and external use. Internally OK load all the manuals to each machine but
you must still check for changes every time they are used. No I still
cannot come up with an example. That does not mean it is wrong, just that
I have no examples, particularly for Javascript which is hardly the
language for heavy maths, come to think of it neither is Pick Basic.
In my own experience the one thing I regret in my switch to Windows is
that I allowed direct access to the screen, it worked great for 25 years
but now I have got to rewrite that bit wheras the parameterised stuff is a
Breeze.
Peter McMurray
"Mark Brown" <mbrown@xxxxxxxxxxxxx> wrote in message
news:HSZvg.31330$uy3.14827@xxxxxxxxxxxxxxxxxxxxxxx
"Peter McMurray" <excalibur21@xxxxxxxxxxx> wrote in message
news:FiZvg.8395$tE5.5081@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Frosty
I am interested in why you want to add javascript. Surely it is the
standardisation of the Display - Presentation Layer - that is one of the
major benefits of any 4gl.
Surely all rules type testing should be at the server end.
Peter McMurray
That's not neccessarily true. The more load we can place (easily) on the
client the better. Thin client, thick client, distributed processing.
Where do you want to do the work? On your one in-house server, or the
super computer that is the 5,000 parallel processors of your internet
users?
Mark
.
- Follow-Ups:
- Re: OpenQM doco in Wiki
- From: Peter McMurray
- Re: OpenQM doco in Wiki
- References:
- OpenQM doco in Wiki
- From: B Faux
- Re: OpenQM doco in Wiki
- From: dawn
- Re: OpenQM doco in Wiki
- From: B Faux
- Re: OpenQM doco in Wiki
- From: frosty
- Re: OpenQM doco in Wiki
- From: Peter McMurray
- Re: OpenQM doco in Wiki
- From: Mark Brown
- Re: OpenQM doco in Wiki
- From: Peter McMurray
- OpenQM doco in Wiki
- Prev by Date: Re: This is an emergency!
- Next by Date: Re: OpenQM doco in Wiki
- Previous by thread: Re: OpenQM doco in Wiki
- Next by thread: Re: OpenQM doco in Wiki
- Index(es):
Relevant Pages
|