[Javascript] JavaScript to PHP variable transfer

[John Warner]

Dave, Sometimes this gets overlooked, but one of our jobs as developers
is managing client expectations. They are free to ask for the moon, it
is our job to make it clear that going to the moon costs $Billions. I
know that sounds silly, but what I mean is they may ask the impossible,
we then have to explain that it is impossible and hopefully have a
reasonable alternative to offer. 

Good luck and have a good weekend

John Warner
mailto:john at jwarner.com

> -----Original Message-----
> From: javascript-bounces at LaTech.edu 
> [mailto:javascript-bounces at LaTech.edu] On Behalf Of David Lovering
> Sent: Friday, August 22, 2003 4:25 PM
> To: [JavaScript List]
> Subject: Re: [Javascript] JavaScript to PHP variable transfer
> 
> 
> Thanks guys!  It is wonderfully refreshing to hear folks 
> agreeing with one's own negative assessments of a situation 
> like this, rather than the customer's complaints about absurd 
> performance issues.
> 
> -- Dave Lovering
> 
> ----- Original Message ----- 
> From: "John Warner" <john at jwarner.com>
> To: "'[JavaScript List]'" <javascript at LaTech.edu>
> Sent: Friday, August 22, 2003 1:19 PM
> Subject: RE: [Javascript] JavaScript to PHP variable transfer
> 
> 
> > Dave, let me second that, your client can't have it both ways.
> >
> > John Warner
> > mailto:john at jwarner.com
> >
> > > -----Original Message-----
> > > From: javascript-bounces at LaTech.edu 
> > > [mailto:javascript-bounces at LaTech.edu] On Behalf Of Roger Roelofs
> > > Sent: Friday, August 22, 2003 2:19 PM
> > > To: [JavaScript List]
> > > Subject: Re: [Javascript] JavaScript to PHP variable transfer
> > >
> > >
> > > Dave,
> > >
> > > Get a new client!  Seriously. I mean it!  User complaint 2 and 
> > > security recommendation 3 are mutually exclusive.  In 
> order for any 
> > > server to maintain state info in a stateless protocol 
> like http, it
> > > must be able
> > > to tag all relevant communication.  In the case of http, 
> cookies, GET
> > > data (like url query strings) and POST data are the only way to do
> > > this.  PHP can either save the session id in a cookie, or 
> as part of
> > > the url.  The user requirement and security requirement 
> removes both
> > > options.
> > >
> > > On Friday, August 22, 2003, at 12:50  PM, David Lovering wrote:
> > >
> > > > Sigh.  I was hoping to save folks the pain --
> > > >
> > > > Apparently, some of the customer's staff objected to an earlier 
> > > > application which used all the conventional "forms" stuff to 
> > > > manage a telecom database
> > > > program.  Their major complaints were (and I'm not kidding!):
> > > >
> > > >     (1)    They didn't like the screen flashing when the
> > > forms updated
> > > >     (2)    They didn't like the gobblety-gook (the URL &
> > > variables) on
> > > > the
> > > > status and link bars
> > > >     (3)    They wanted it to be faster (much, much faster)
> > > >     (4)    The IT guys objected to the bandwidth being used
> > > every time
> > > > a
> > > > form updated
> > > >
> > > > This was the state of things -- right up to the time 
> that they got 
> > > > "hacked" (presumably through their web application, although 
> > > > nobody
> > > has shown
> > > > me a
> > > > P.M. of the event). They called in some high-powered security 
> > > > consultant who said (and again, I'm not kidding!)
> > > >
> > > >     (1)    Disable all forms-related transfers
> > > >     (2)    Only do transactions over SSLv3 (makes sense)
> > > >     (3)    Don't use cookies on the client machines -- FOR
> > > ANYTHING!!!
> > > >
> > > > The VP in charge of software development (who, in my
> > > opinion shouldn't
> > > > be in
> > > > charge of shoelaces) agreed to all of these 
> considerations, carte 
> > > > blanche.
> > > >
> > > > Now I have to rebuild the application (which merges 
> bits of Remedy 
> > > > with bits of GoldMine) with both sets of constraints in mind -- 
> > > > however unpleasant and
> > > > impossible they are.  I have ways of beating all of these,
> > > but it is
> > > > sort of
> > > > like sucking spaghetti through a straw while standing on your 
> > > > head; messy, highly unorthodox, and very, very strange to see.  
> > > > Having done a simple-minded scheduling and traffic analysis, it 
> > > > was
> > > decided to dump
> > > > Remedy
> > > > and Goldmine altogether (security, speed, and a lousy user 
> > > > interface probably had a lot to do with that), and some 
> prior bad 
> > > > experiences with Microsoft IIS servers moved everything over to 
> > > > Apache, with
> > > a hardened
> > > > enterprise server edition.  Having decided that transforming 
> > > > everything to a pure-Java environment would exceed the pain 
> > > > tolerance for initial applet
> > > > down-load delays, the only bits left were PHP, JavaScript,
> > > and whatever
> > > > XML/DHTML fragments could continue to function in this lame 
> > > > environment. All this was before they brought me on board.
> > > >
> > > > Ugly, ain't it?
> > > >
> > > > -- Dave Lovering
> > >
> > > _______________________________________________
> > > 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
> >
> >
> 
> 
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu 
> https://lists.LaTech.edu/mailman/listinfo/javascript
>