[Javascript] JavaScript to PHP variable transfer

David Lovering dlovering at gazos.com
Thu Aug 21 15:42:58 CDT 2003


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
>




More information about the Javascript mailing list