[Javascript] JavaScript to PHP variable transfer

[Chris Tifer]

If you strictly want this for session variables, why are cookies not an
option again? And what could possibly be needed on the server if they've
turned off all functionality as you've implied.

I still do not get the gist of this project you're working on at all. It's
just a bunch of vague talk about how hundreds of form elements must stay the
same and you can't do anything with them on the server.  Sounds more like a
quiz to me and one of us has to come up with the best theoretical
scenario...

Chris Tifer
http://emailajoke.com






----- Original Message ----- 
From: "David Lovering" <dlovering at gazos.com>
To: "[JavaScript List]" <javascript at LaTech.edu>
Sent: Thursday, August 21, 2003 4:42 PM
Subject: Re: [Javascript] JavaScript to PHP variable transfer


> Legacy issue -- fist-fights are even now being fought on that point.  Good
> call!
>
> Yep.  I've put on the table "wish-list" items for the next generation -- 
but
> for now,
> the show is driven by pushing the status-quo forward.  I'd like to see
> one-time-use
> session-id variables (encrypted by MD5 or better), force-scrubbed
> immediately after use,
> and running on top of a hardware-expedited IPSECv2 pipe to do all of this.
> Now if
> Santa Claus can only come through...
>
> -- Dave Lovering
>
> ----- Original Message ----- 
> From: "Mike Dougherty" <mdougherty at pbp.com>
> To: "'[JavaScript List]'" <javascript at LaTech.edu>
> Sent: Thursday, August 21, 2003 12:32 PM
> Subject: RE: [Javascript] JavaScript to PHP variable transfer
>
>
> > You're running the webserver on the same box as the SQL server?
> >
> > I would think that would be the first problem to convince the customer
> > to focus on :)
> >
> > >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.
> >
> >
> > It also sounds like the customer is being a bit extreme (and potentially
> > misguided) about "security" and the ideal usage of bandwidth.  By the
> > time you build a sufficiently clever mechanism for working in the
> > specifications they've given you, they will have spent enough that they
> > could have thrown hardware and bandwidth at this problem until a far
> > less clever developer could maintain it.  I'm guessing you can't bring
> > this up, but would it be worth it to discuss a more flexible
> > configuration for basic assumptions to start with?
> >
> >
> > _______________________________________________
> > Javascript mailing list
> > Javascript at LaTech.edu
> > https://lists.LaTech.edu/mailman/listinfo/javascript
> >
>
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript