[Javascript] JavaScript to PHP variable transfer

[David Lovering]

----- Original Message ----- 
From: "Chris Tifer" <christ at saeweb.com>
To: "[JavaScript List]" <javascript at LaTech.edu>
Sent: Thursday, August 21, 2003 11:00 AM
Subject: Re: [Javascript] JavaScript to PHP variable transfer


>
> > Firstly, the client and the server are on opposite sides of a secured
> > pipe -- and CGI/BIN stuff and cookies have both been shut off.
> Completely.
> > Non-negotiably, and forever.  I barely have the means to do
> > session-variables (sans cookies), and can't rely on it because they are
> > talking about
> > shutting session-variables down on the server.  Anyway,
session-variables
> > without cookies is pretty much a useless gesture.
>
> A session variable IS a cookie.

Precisely, although some PHP session variables continue to exist even after
the ability to write/read cookies has been curtailed.  [Purely a
nomenclature
coincidence].

>
> > Secondly, there are several thousand miles between the client machines
and
> > the server(s), so latency can be an issue -- and a full-fledged forms
dump
> > typically takes longer than merely porting one or two variables back and
> > forth.  Multipled by tens of thousands of forms transactions per-day,
this
> > would
> > be bad.
>
> Unless you're sending back a ton of data, processing forms does not
> take any longer than any other requests that I know of. And as for the
> comparison of "full-fledged form" vs. "1 or 2 variables", how can you
> compare
> them since there is no way of just sending variables arbitrarily to a
> server - at
> least in the manner of what you're hoping to do.

In point of fact, a "form" with 300+ fields and widgets DOES take longer to
transfer than does one or two variables -- even if the CGI/BIN stuff weren't
turned off.

In answer to your second point, actually there is -- via sockets on SSL and
(God bless 'em!) named pipes.  Works great over encrypted channels, but a
hassle to set up.  See your own comment --

> To get any variable to a server, you're pretty much going to need to use a
> form (or a querystring which is basically the same thing) unless you have
an
> open socket in which you can send info back and forth.

... snip

>
> I'm not sure what it is you're trying to accomplish as you're being fairly
cryptic, but this sounds like a design issue to me.  Taking your same
example of how sending a bunch of data back and forth can be bad, choosing
to send little bits at a time is even moreso as the processing on the server
is not going to take as long as transfer rates between client/server.

That is precisely the point -- we want the server to spend its spare CPU
cycles resolving big gnarly SQL queries, and not doing big gnarly forms
transfers -- particularly if 80% of the form isn't applicable to generating
the necessary SQL queries.  This may cause many additional small sessions of
variable transfers, but it also generates lots and lots of "idle" time
between output dumps while the queries are in process.  Anyhow, the most
annoying constraints were set in stone by the customer, and I have to play
along however I can.  Frankly, I wish YOU were my customer -- your viewpoint
is much like mine was prior to this project.

>
> Also, physical location (distance) really has nothing to do with transfer
> rates.
> You can be close to your machine, but if it has to make multiple hops,
it's
> going to take longer than if you were 10,000 miles away that didn't have
> many
> different hops.

True, but not particularly germane.  Maybe I'm merely being dense.  Let's
just say that the time elapsed while passing variables from the client to
the server(s) is largely spent with neither of them doing anything in
particular, unless the server already has SQL queries in progress.

> > One of the key sticking points that this picture causes is a need to
follow the JavaScript DOM chains from window to window, pulling key bits off
of
> > different panes and then presenting them in an acceptable form to the
server PHP functions for accessing the various database(s) this application
is
> > built around.  Having a relatively painless way for PHP to interrogate
JavaScript for both the DOM mapping and the field values on-the-fly would
> > be a tremendous help, particularly as the screen content can be
selectively varied on a rather massive scale.
> >
> > Capiche?

> No, I don't capiche. Does anyone else?

Obviously, my lucidity is being eroded by the "impossible" nature of the
problem.

>
> That being said, there is a way of remote javascripting, but I don't
believe
> you're going to have any luck with any browsers other than IE.

Right now, I'd settle for IE (cough, gag)...  However, the customer's server
is NOT a Microsoft IS server (thank God for small favors), so many of the
generic ASP methods (and those similar) don't apply.

I'm sorry if I'm irritating the body politic with a JavaScript problem so
far removed from the mainstream, but this is struck me as just the sort of
difficult problem this forum is good at solving.

-- Dave