[nycphp-talk] AJAX and State

[Kenneth Downs]

One thing that seems to have gone unsaid in the praise for Ajax is its
ability to radically transform how we maintain state.

The web server session is our basic mechanism for storing information
between requests. But it gets clumsier and clumsier to try to maintain
complex state across many page requests when you use a session.
Ingenious minds have put their will to the problem and come up with
workable systems, but all of them are complicated because of the nature
of the problem.

That problem, stated here, is simply the problem of tracking what I'll
call the "context" of a user's session. Some elements of a session are
fixed: the user id, the password, a few other things, but almost
everything that we need to track is always changing. A basic example: a
list of search results. Where do you store it? When the user hits,
"NEXT PAGE", how do you know what to do? If you are using a session,
what happens if he opens a new window and has two search results sets up
for two different tables?

Ajax solves this problem neatly by letting you move all state [1] into
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed, the
UI.

I've been converting the basic Andromeda UI code over to a completely
AJAX system [1], and have found my code radically simplified and far
smoother, due almost entirely to the moving of all state information to
the browser. Hurray for Ajax!

[1] Here I'll use "state" to mean the changing context of user requests,
and assume we are still using the session for User_id and password.

[2] Andromeda is used to make database applications for businesses, we
don't care in this case about google following our links.

[Jon Baer]

Personally ... I think even broader ideas like Dojo Offline (http://
dojotoolkit.org/offline) and Google Gears (http://gears.google.com/)
takes it to an even further level which has not been tapped (yet).
Now if only you can sneak it into a project ;-)

- Jon

Post by Kenneth Downs
One thing that seems to have gone unsaid in the praise for Ajax is
its ability to radically transform how we maintain state.
The web server session is our basic mechanism for storing
information between requests. But it gets clumsier and clumsier to
try to maintain complex state across many page requests when you
use a session. Ingenious minds have put their will to the problem
and come up with workable systems, but all of them are complicated
because of the nature of the problem.
That problem, stated here, is simply the problem of tracking what
I'll call the "context" of a user's session. Some elements of a
session are fixed: the user id, the password, a few other things,
but almost everything that we need to track is always changing. A
basic example: a list of search results. Where do you store it?
When the user hits, "NEXT PAGE", how do you know what to do? If
you are using a session, what happens if he opens a new window and
has two search results sets up for two different tables?
Ajax solves this problem neatly by letting you move all state [1]
into the browser. This makes sense from an architectural viewpoint
because we are putting this context information close to where it
is needed, the UI.
I've been converting the basic Andromeda UI code over to a
completely AJAX system [1], and have found my code radically
simplified and far smoother, due almost entirely to the moving of
all state information to the browser. Hurray for Ajax!
[1] Here I'll use "state" to mean the changing context of user
requests, and assume we are still using the session for User_id and
password.
[2] Andromeda is used to make database applications for businesses,
we don't care in this case about google following our links.
--
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com www.andromeda-project.org
631-689-7200 Fax: [phone]
cell: 631-379-0010
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php

[Kenneth Downs]

I have not looked at Dojo yet, though they have been on "the list" for
awhile.

The firefox extensions are now looking really exciting. I am looking to
download or write an extension that will let me ship photographs from a
camera directly to the database, and also to intercept bar code scans
and do some intelligent page routing. Fun stuff.

Post by Jon Baer
Personally ... I think even broader ideas like Dojo Offline
(http://dojotoolkit.org/offline) and Google Gears
(http://gears.google.com/) takes it to an even further level which has
not been tapped (yet). Now if only you can sneak it into a project ;-)
- Jon

Post by Kenneth Downs
One thing that seems to have gone unsaid in the praise for Ajax is
its ability to radically transform how we maintain state.
The web server session is our basic mechanism for storing information
between requests. But it gets clumsier and clumsier to try to
maintain complex state across many page requests when you use a
session. Ingenious minds have put their will to the problem and come
up with workable systems, but all of them are complicated because of
the nature of the problem.
That problem, stated here, is simply the problem of tracking what
I'll call the "context" of a user's session. Some elements of a
session are fixed: the user id, the password, a few other things, but
almost everything that we need to track is always changing. A basic
example: a list of search results. Where do you store it? When the
user hits, "NEXT PAGE", how do you know what to do? If you are using
a session, what happens if he opens a new window and has two search
results sets up for two different tables?
Ajax solves this problem neatly by letting you move all state [1]
into the browser. This makes sense from an architectural viewpoint
because we are putting this context information close to where it is
needed, the UI.
I've been converting the basic Andromeda UI code over to a completely
AJAX system [1], and have found my code radically simplified and far
smoother, due almost entirely to the moving of all state information
to the browser. Hurray for Ajax!
[1] Here I'll use "state" to mean the changing context of user
requests, and assume we are still using the session for User_id and
password.
[2] Andromeda is used to make database applications for businesses,
we don't care in this case about google following our links.
--Kenneth Downs
Secure Data Software, Inc.
www.secdat.com www.andromeda-project.org
631-689-7200 Fax: [phone]
cell: 631-379-0010
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php

_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php

[Hans Zaunere]

Hi,

Post by Kenneth Downs
One thing that seems to have gone unsaid in the praise for Ajax is its
ability to radically transform how we maintain state.
The web server session is our basic mechanism for storing information
between requests. But it gets clumsier and clumsier to try to
maintain complex state across many page requests when you use a
session. Ingenious minds have put their will to the problem and come
up with workable systems, but all of them are complicated because of
the nature of the problem.
That problem, stated here, is simply the problem of tracking what I'll
call the "context" of a user's session. Some elements of a session
are fixed: the user id, the password, a few other things, but almost
everything that we need to track is always changing. A basic
example: a list of search results. Where do you store it? When the
user hits, "NEXT PAGE", how do you know what to do? If you are using
a session, what happens if he opens a new window and has two search
results sets up for two different tables?

We've encountered similar problems, which are especially prevelant in a web
2.0 super-duper-magic type of site (ie, tabbed browsing, draggable modules,
etc).

Post by Kenneth Downs
Ajax solves this problem neatly by letting you move all state [1] into
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
the UI.

I'm not sure what you mean, though, by keeping state in the browser. Here's
essentially what's work for me in the past:P

-- typical session ID is generated and the browser is cookied, just like
with any other site. this sets a session for the entire browser - nothing
special here

-- the Javascript code is written to persist the browser's cookie, so it's
requests appear to the server just like any other regular browser request

-- the server is now getting hit with numerous requests - some are the
"whole browser" and some are simply partial requests (Ajax/JS requests).
These requests are typically out of the classic order that you'd expect a
browser to produce, since you can't always assume the timing of the user's
browser.

The Ajax requests hit a certain set of URLs, let's say /Ajax/, on the
server. The server knows to handle these requests specially, which in
effect creates sub-sessions. That is to say, for every complex set of Ajax
operations, the server is maintaining it's own sub-set of data. For
instance, search results and the search criteria, which is attached strictly
to a single module or Ajax part of the page.

---
Hans Zaunere / President / New York PHP
www.nyphp.org / www.nyphp.com

[bz-gmort]

Post by Kenneth Downs
Ajax solves this problem neatly by letting you move all state [1] into

Post by Kenneth Downs
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
the UI.

I'm not sure what you mean, though, by keeping state in the browser. Here's
essentially what's work for me in the past:P

I read the above as, to take a simple example:

A user searches for all employee records in NYC.
He browses to page 3 of that result set
Than he clicks on a record to edit it.
When he completes editing the record and clicks "save", he wants to be
returned to page 3 of the result set, with a message across the top of
the screen saying "Record XYZ updated successfully".

With sessions, you could store the search and page number he was on in
the session, so when he clicks save he returns to the page he came from.

Problem:
A user searches for all employee records in NYC.
He browses to page 3 of that result set
Than he clicks on a record to edit it.
He doesn't recall the exact phrase used that he wants to change some
piece of data to to adopt a standard.
He opens a second tab/browser and searches for all employees in Baltimore.
He browses through to the fourth page and finds a record he used that on
and opens it
He then switches back to the window where he is editing the record and
copies the phrase from one window to the other.
He completes processing and clicks save.
He is returned to page 4 of the Baltimore search(his last viewed search
page) and not the NY search


Ajax tracking state:
A user searches for all employee records in NYC
The search result is loaded in a hidden div which is then made visible
via AJAX
He browses to page 3 of the search results
Then he clicks on a record to edit it
Using Ajax, the listing is now hidden and the record is loaded in a
hidden div and then made visible
He doesn't recall the exact phrase...
....
(user now has 2 windows open, 1 with the NYC employee being edited, 1
with the Baltimore employee being edited - yes this is stupid, he should
be viewing not editing the Baltimore data, but such is the way of life)
He makes the change to the NYC employee and clicks save
using AJAX, the data is saved, the employee edit div data is set to
"employee XYZ successfully update", while the employe list div is made
visible.

So in this manner, using Ajax his path/state is saved in the browser
window and he returns to precisely where he was.


The above being a stupid example that could have been easily tracked in
other ways(a single line of data in each row specifying the search
criteria, the page, and perhaps the result set data identifier). But
when you have 30 or 40 pieces of data to track and return to the user,
it starts getting more complicated.

Of course, all this could have been done with sessions and setting an
identifier for each browser window. So I would not say this is
something "extra" you get with Ajax. What it rather does is make less
work for the coder. Using cookies, sessions, or passing variables
through the forms you would have had to actively code for all that state
information. By keeping it all stored in the browser and not reloading
the data, you don't have to track it at all.


OTOH it does have it's own price and problems. All these nifty little
ajax scripts maintaining data on a browser start to eat up memory.
Browsers that weren't designed on the assumption of maintaining and
adding more and more variables, instead they assumed each page
navigation would discard all the old variables and create a new set will
start leaking memory. And after sitting on one of these cool sites for
4-6 hours, your browser could start dragging the browser or system
down. In addition, since all these links ARE often links, you get
someone like me who comes along and opens up windows in new tabs when he
wants to work on something specific, and you can get a lot of
unpredictable results if you were counting on the data in the browser to
be there for context and I suddenly opened a new tab.

But hey, everything has a cost, right?

[tedd]

Post by Kenneth Downs
Ajax solves this problem neatly by letting you move all state [1] into

Post by Kenneth Downs
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
the UI.

I'm not sure what you mean, though, by keeping state in the browser. Here's
essentially what's work for me in the past:P

I read your "simple example" and see that you can do it w/wo ajax --
but I don't see the advantage in using ajax other than presentation.

Please correct me if I'm wrong, but isn't ajax (and ahah) only a
means to communicate with the server without causing a refresh? Does
ajax provide something beyond that?

Cheers,

tedd

[Kenneth Downs]

Post by tedd

Post by Kenneth Downs
Ajax solves this problem neatly by letting you move all state [1] into

Post by Kenneth Downs
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
the UI.

I'm not sure what you mean, though, by keeping state in the
browser. Here's
essentially what's work for me in the past:P

I read your "simple example" and see that you can do it w/wo ajax --
but I don't see the advantage in using ajax other than presentation.
Please correct me if I'm wrong, but isn't ajax (and ahah) only a means
to communicate with the server without causing a refresh? Does ajax
provide something beyond that?

Yes, AJAX provides benefits beyond its simple ability to communicate w/o
a refresh.

BZ's example is exactly what I've been coding the past week or so, and
it is far simpler keeping track of things in the browser than on the
server, particularly with tabbed browsing.

Here is a smaller example. User has a form up to do a database insert
-- such as create a new insurance company entry. They have some
duplicate information and their save will fail, but they don't know and
they hit save. What happens?

-> In non-ajax world, you submit the form. The data is validated and a
list of errors is generated. You regenerate the HTML, populate the form
with the original values, place the error notices, and send it back.

-> In the ajax world you do an Ajax submit and get back a JSON object
that contains an array listing the errors. The response handler puts up
a popup telling you there were errors, then it adds the errors next to
the inputs that have problems and changes their css class to make them
red (or whatever).

- no regenerating the form on the server
- no re-assigning values (they were never changed)
- no html processing AT ALL on server, just take the data and run
the INSERT

Doing this requires that some state be stored in the browser as the
properties of a global object. That was the thrust of my original post,
and bz fleshed out scenarios where it would be used. Here I've tried to
give a very specific example of how it changes your coding practices.

Post by tedd
Cheers,
tedd

[bz-gmort]

Post by Kenneth Downs
BZ's example is exactly what I've been coding the past week or so, and
it is far simpler keeping track

^^^^^
I'll take this as a hint that I need to create a sigfile with my name
and such in it.

[Kenneth Downs]

Post by bz-gmort

Post by Kenneth Downs
BZ's example is exactly what I've been coding the past week or so,
and it is far simpler keeping track

^^^^^
I'll take this as a hint that I need to create a sigfile with my name
and such in it.

Unless you've got secrets to keep :)

Post by bz-gmort
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php

[tedd]

Post by Kenneth Downs

Post by tedd

Post by Kenneth Downs
Ajax solves this problem neatly by letting you move all state [1] into

Post by Kenneth Downs
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
the UI.

I'm not sure what you mean, though, by keeping state in the
browser. Here's
essentially what's work for me in the past:P

I read your "simple example" and see that you can do it w/wo ajax
-- but I don't see the advantage in using ajax other than
presentation.
Please correct me if I'm wrong, but isn't ajax (and ahah) only a
means to communicate with the server without causing a refresh?
Does ajax provide something beyond that?

Yes, AJAX provides benefits beyond its simple ability to communicate
w/o a refresh.
BZ's example is exactly what I've been coding the past week or so,
and it is far simpler keeping track of things in the browser than on
the server, particularly with tabbed browsing.
Here is a smaller example. User has a form up to do a database
insert -- such as create a new insurance company entry. They have
some duplicate information and their save will fail, but they don't
know and they hit save. What happens?
-> In non-ajax world, you submit the form. The data is validated
and a list of errors is generated. You regenerate the HTML,
populate the form with the original values, place the error notices,
and send it back.
-> In the ajax world you do an Ajax submit and get back a JSON
object that contains an array listing the errors. The response
handler puts up a popup telling you there were errors, then it adds
the errors next to the inputs that have problems and changes their
css class to make them red (or whatever).
- no regenerating the form on the server
- no re-assigning values (they were never changed)
- no html processing AT ALL on server, just take the data and run
the INSERT
Doing this requires that some state be stored in the browser as the
properties of a global object. That was the thrust of my original
post, and bz fleshed out scenarios where it would be used. Here
I've tried to give a very specific example of how it changes your
coding practices.

Yes, but I can do all of that via javascript without touching the
server or using ajax.

Just keep the user entering data until the data is correct, then
submit the form via ajax or as one normally would via a form submit.

So, I don't see the ajax advantage here.

Granted, I may be missing the point, are you saying that you can
communicate data between two open windows on the client side?

Cheers,

tedd

[Dell Sala]

Post by tedd
Just keep the user entering data until the data is correct, then
submit the form via ajax or as one normally would via a form submit.
So, I don't see the ajax advantage here.

The problem with what you're describing is that all your form
validation code (business logic) is deployed to the browser as
javascript. For serious applications, the server cannot rely on the
client to take care of things like validation, because they can
easily be bypassed.

What ajax allows you to do is keep the heavy lifting business logic
on the server (where it belongs), but have your web page change it's
own state without having to ask the server to redraw an entire
document every time it needs some new information, or a calculation
performed.

For example: you could authenticate a user without having to refresh
the page. There is no way to do that without asking the server to
verify credentials. Ajax (or some other kind of remoting) is required
if you want to avoid a page refresh.

-- Dell

[tedd]

Post by Dell Sala

Post by tedd
Just keep the user entering data until the data is correct, then
submit the form via ajax or as one normally would via a form submit.
So, I don't see the ajax advantage here.

The problem with what you're describing is that all your form
validation code (business logic) is deployed to the browser as
javascript. For serious applications, the server cannot rely on the
client to take care of things like validation, because they can
easily be bypassed.
What ajax allows you to do is keep the heavy lifting business logic
on the server (where it belongs), but have your web page change it's
own state without having to ask the server to redraw an entire
document every time it needs some new information, or a calculation
performed.
For example: you could authenticate a user without having to refresh
the page. There is no way to do that without asking the server to
verify credentials. Ajax (or some other kind of remoting) is
required if you want to avoid a page refresh.
-- Dell

-- Dell:

Well of course, you never trust anything on the client side and it
makes sense to do the user input checks client-side and then validate
on server side, but that's not what we've (at at least me) have been
discussing.

The only question I've asked here is what beyond communication
without refresh does ajax provide and the only answer I've received
is "nothing", which is what I expect.

Thanks for your time.

Cheers,

tedd

[Elliotte Harold]

Dell Sala wrote:
=

The problem with what you're describing is that all your form validation
code (business logic) is deployed to the browser as javascript. For
serious applications, the server cannot rely on the client to take care
of things like validation, because they can easily be bypassed.

Of course not, which is why you double validate: on the client to help
the honest user and on the server to keep out the hackers. This is true
whether we're using HTML forms + JavaScript, XForms, or Web Forms 2.0.
Client side validation does not replace server side validation.

What ajax allows you to do is keep the heavy lifting business logic on
the server (where it belongs), but have your web page change it's own
state without having to ask the server to redraw an entire document
every time it needs some new information, or a calculation performed.

Yes, though that's actually not what Ken was talking about. :-)

[Mark Armendariz]

Post by tedd

Post by Kenneth Downs
Ajax solves this problem neatly by letting you move all state [1] into

Post by Kenneth Downs
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
the UI.

I'm not sure what you mean, though, by keeping state in the
browser. Here's
essentially what's work for me in the past:P

I read your "simple example" and see that you can do it w/wo ajax --
but I don't see the advantage in using ajax other than presentation.
Please correct me if I'm wrong, but isn't ajax (and ahah) only a means
to communicate with the server without causing a refresh? Does ajax
provide something beyond that?

That's exactly what's provided by XHR (what's usually referred to as
ajax) - a means of mini-requests instead of full-page requests. You
still have to maintain a session id and everything when communicating
with the server, but with a well thought out application, you can skip a
lot of the back and forth between the server and hence keep a lot of the
heavy lifting that involves simple client-side interaction on the client.

Ideally we should be molding our requests around usability, which is
what the ubiquity of XHR allows us to finally do. When we build apps
for the web, we tend to mold usability around server requests. It might
make sense to do so after writing web apps for a while, but to users who
aren't as affiliated, waiting for 3 or 4 pages to load to fill out a
form doesn't make very much sense.

For instance, your user wants to register at your site. The user enters
their username, password, address, personal information, etc and
submit. The username is already in use, so the entire form has to be
reloaded, all the previously entered values have to be shown. This is a
large request on the server (check the db for a username, revert to the
last page with posted data, regenerate the template and fill the form
values). With an XHR capable form, as soon as you tab off of the
username field, a smaller request is made to check the username, and the
user knows immediately if they can continue. No reloading of the page,
minimal server request for the one thing needed instead of the whole
thing. Saves bandwidth, but far more importantly, saves the user's time
and patience.

It mostly depends on what you're building. There's generally not much
use for XHR on a blog app, unless you're adding some bells and whistles
that people can use (a poll that won't refresh the page and hence force
the reader to lose their place, for instance). But on a CMS app or
other type of application that requires a good deal of communication
with the server without having to reload an entire page, it can change
the entire way you program.

[tedd]

Post by Mark Armendariz

Post by tedd

Post by Kenneth Downs
Ajax solves this problem neatly by letting you move all state [1] into

Post by Kenneth Downs
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
the UI.

I'm not sure what you mean, though, by keeping state in the
browser. Here's
essentially what's work for me in the past:P

I read your "simple example" and see that you can do it w/wo ajax
-- but I don't see the advantage in using ajax other than
presentation.
Please correct me if I'm wrong, but isn't ajax (and ahah) only a
means to communicate with the server without causing a refresh?
Does ajax provide something beyond that?

That's exactly what's provided by XHR (what's usually referred to as
ajax) - a means of mini-requests instead of full-page requests.

Mark:

-snip- Thanks for the examples.

The examples you provided basically do only one thing -- they
communicates with the server without a refresh -- nothing more.

I know all about filling in forms, checking if the user is registered
or not, and numerous other aspects of how to use ajax to update web
pages without refresh to enrich the user's experience. Been there,
done that.

I also know how to use ajax to communicate with php to do stuff, like so:

http://webbytedd.com/b/timed-php/

So, I am familiar with ajax. But, everything I've seen thus far is
simply using the get/post aspects of javascript to communicate with
the server, nothing more.

Now, what I am asking is not how ajax communication with the server
can be used, but rather is there anything beyond that which ajax can
provide?

Another way of asking this question is, "Besides not triggering a
refresh, what can ajax do that php can not?"

Note: I know that technically, ajax uses xml, but in the cases we've
discussed thus far, I'm assuming that this has been limited to
responseTEXT property and not to xml, correct?

Cheers,

tedd

[Dell Sala]

Post by tedd
Now, what I am asking is not how ajax communication with the server
can be used, but rather is there anything beyond that which ajax
can provide?
Another way of asking this question is, "Besides not triggering a
refresh, what can ajax do that php can not?"

At the root of things, that IS all ajax provides -- a way to issue
requests without having to refresh the entire browser window.
However, this opens up all kinds of other possibilities when it comes
to building a user interface. All of a sudden you can design things
to behave much more like a networked desktop application instead of a
series of isolated, stateless documents.

The basic pattern becomes
1) deploy an html/javascript application to the browser
2) the html/javascript application communicates with the server to
get any information it needs to change it's own state

You get a very nice separation between business and presentation
source code.

Here's my beef: ** JavaScript is painful **

I've found the amount of code I have to write has increased
dramatically. I write a little less php, but TONS more javascript.
And debugging javascript sucks... Browser compat. issues just kill
the experience for me. And there are performance issues too.

Ajax is great because it has given us a new way to think about
developing web apps. But I feel this model needs a better platform...
Flex anyone?

-- Dell

[tedd]

Post by Dell Sala

Post by tedd
Now, what I am asking is not how ajax communication with the server
can be used, but rather is there anything beyond that which ajax
can provide?
Another way of asking this question is, "Besides not triggering a
refresh, what can ajax do that php can not?"

At the root of things, that IS all ajax provides

OK then, my confusion has been cleared.

From many of the post here, I thought someone had discovered something new.

My only fault with ajax is that many people make it out to be
something more complicated than what it actually is -- when in fact,
it's pretty simple.

Sure it's application can get complicated as to what calls what and
when, but when you distill what it does down to the basics, things
become much simpler. I like simple.

Thanks everyone,

Cheers,

tedd

[Elliotte Harold]

Post by tedd
From many of the post here, I thought someone had discovered something new.

Discovering something truly new is rare. There's almost always someone
who discovered it before you. Sometimes we don't believe them, though,
until we discover it for ourselves.

Interestingly though what Ken rediscovered is not AJAX. It's one of the
design principles of REST: all application state should be stored on the
client and passed to the server with each request. That he discovered
this in the context of AJAX is an implementation detail.

[Kenneth Downs]

Post by Elliotte Harold

Post by tedd
From many of the post here, I thought someone had discovered
something new.

Discovering something truly new is rare. There's almost always someone
who discovered it before you. Sometimes we don't believe them, though,
until we discover it for ourselves.
Interestingly though what Ken rediscovered is not AJAX. It's one of
the design principles of REST: all application state should be stored
on the client and passed to the server with each request. That he
discovered this in the context of AJAX is an implementation detail.

Actually the idea was that you don't have to pass the state to the
server, it stays on the client. But otherwise yes that is the idea.

[tedd]

Post by Elliotte Harold

Post by tedd
From many of the post here, I thought someone had discovered something new.

Discovering something truly new is rare. There's almost always
someone who discovered it before you. Sometimes we don't believe
them, though, until we discover it for ourselves.

Let me restate that "discovered something new to me" -- which isn't
that hard to do.

Post by Elliotte Harold
There are no sessions, or at least there shouldn't be in
well-designed Web applications.

Ouch -- straight through the heart, and now you've got my head hurting too.

In all my "applications" I use sessions to pass significant variables
around from page to page. Each page is doing something different for
the user and it make sense to me to break the routines into different
groups and string them together using sessions.

If the user opts out at any time, then no harm done. If I want the
user to have a state to come back to, then I use cookies "on-the-fly"
to store that on the user's machine. For example:

http://ancientstones.com

If a user is looking through the widgets and has a search criteria
they like, it's saved on their machine as a cookie and when they
return, it's still there.

However, if the data is "sensitive", then I require a log-in. If the
user leaves in the middle of a session, and I want to store the
session for the user, then I use the session id and mysql to store
data and state on the server and the sid in a cookie on the user's
machine. When they return, I check session id's and require another
log-in before presenting "sensitive" data and they're back where they
were.

All pretty simple stuff.

If someone told me that I couldn't use sessions, then I'm not sure
how I would handle "sensitive" data. For example, I'm currently
working on a site that provides papers, articles, tapes, cds,
conferences, seminars, and videos to it members. However, they must
be currently paid-up members to access the goodies.

My solution is to simply require them to log-in and set a session
auth variable to OK and turn them loose. Then they have access to all
the goodies.

While what they ask for on the site is provided in the URL via a GET,
and as such, they could bookmark it and/or send the URL to someone
else -- but they can't get at the goodies without being logged-in
(i.e., session auth variable set to OK).

Again, all pretty simple stuff.

This works for me -- but, how do you do this without using sessions?

Cheers,

tedd

[Elliotte Harold]

My solution is to simply require them to log-in and set a session auth
variable to OK and turn them loose. Then they have access to all the
goodies.
While what they ask for on the site is provided in the URL via a GET,
and as such, they could bookmark it and/or send the URL to someone else
-- but they can't get at the goodies without being logged-in (i.e.,
session auth variable set to OK).
Again, all pretty simple stuff.
This works for me -- but, how do you do this without using sessions?

HTTP basic or digest authentication would do exactly this with less work
on your part. There are other alternatives if that doesn't meet your
needs, but HTTP authentication is by far the simplest approach.

[Gary Mort]

Post by tedd
Another way of asking this question is, "Besides not triggering a
refresh, what can ajax do that php can not?"

PHP cannot control the browser presentation, it can merely provide
static information to the browser.
Javascript can control the browser presentation, and it can be generated
by PHP
AJAX merely allows you to combine the functionality of javascript with
the dynamic data access of PHP(or any other CGI script) in order to put
the two together in a more dynamic fashion. It has sparked some
innovations in presenting and packaging data generated by CGI that than
make the whole thing reusable(for example, frameworks which pull all the
dynamic data down to the server and then allow one to work offline and
then sync up to the server. Of course, the curmudgeon in me would say
"well, besides using a web browser, what can this do that a Lotus Notes
client can't? " :-0 and the answer is it can be done without charging
hundreds of dollars per user.)

I see web browser applications slowly approaching the full power of a
Notes Application from over 5 years ago. But they do it in a cross
platform, affordable manner. Still, with notes I knew precisely what
functions would work on every system with a notes client plus had
certain levels of security unavailable with a browser without a lot of
work, so it has it's place in the corporate environment.

[tedd]

Post by Gary Mort

Post by tedd
Another way of asking this question is, "Besides not triggering a
refresh, what can ajax do that php can not?"

PHP cannot control the browser presentation, it can merely provide
static information to the browser.

Ah yes, my question was somewhat lame. I know that php can't control
client-side. But, that's not what I was asking.

Post by Gary Mort
Javascript can control the browser presentation, and it can be
generated by PHP
AJAX merely allows you to combine the functionality of javascript
with the dynamic data access of PHP(or any other CGI script) in
order to put the two together in a more dynamic fashion. It has
sparked some innovations in presenting and packaging data generated
by CGI that than make the whole thing reusable(for example,
frameworks which pull all the dynamic data down to the server and
then allow one to work offline and then sync up to the server.

Yeah, like what I've seen in jQuery -- very exciting stuff. This impressed me:

http://webbytedd.com/a/move/

Post by Gary Mort
Of course, the curmudgeon in me would say "well, besides using a web
browser, what can this do that a Lotus Notes client can't? " :-0 and
the answer is it can be done without charging hundreds of dollars
per user.)

Next year it will be cheaper.

Post by Gary Mort
I see web browser applications slowly approaching the full power of
a Notes Application from over 5 years ago. But they do it in a
cross platform, affordable manner. Still, with notes I knew
precisely what functions would work on every system with a notes
client plus had certain levels of security unavailable with a
browser without a lot of work, so it has it's place in the corporate
environment.

And, perhaps the year after that those problems will be solved.

My slant, which is of no importance, is that web application
developers have to be masters of several languages -- one won't do.
At present, a good grasp of php, javascript, mysql, css, and ajax
makes for good company in application development.

From the perspective of 42 years of programming, to me all languages
are converging anyway -- I don't see that much difference now and I
expect that one day there will be only one.

Cheers,

tedd

[bz-gmort]

Post by tedd
My slant, which is of no importance, is that web application
developers have to be masters of several languages -- one won't do. At
present, a good grasp of php, javascript, mysql, css, and ajax makes
for good company in application development.

Hmm...has this ever not been the case?

I mean, with lotus notes I had to know:
Lotusscript, Notes Formula, Notes UI design, a little graphics editing,
and SQL
Over the years, Java and Javascript got thrown into the mix as well.

Heck, before that with my very first job(writing user interfaces in an
IBM IDE called PAS, then renamed as Visualizer, before dying) I had to know:
SQL, PAS, DB2 Query Manager, Rexx, the DB2 CLI, and C(for those
functions that PAS just did not do and we had to write specialized
interfaces for. Like the barcode printer. Oh was that a joy to work with!)


:-)

[Steve Manes]

Now, what I am asking is not how ajax communication with the server can
be used, but rather is there anything beyond that which ajax can provide?
Another way of asking this question is, "Besides not triggering a
refresh, what can ajax do that php can not?"

You're right: nothing. But just focusing on the get/post mechanics as a
baseline for comparison is kinda reducing the question to, "is there
anything client/server can do that client/server can't do?"

Ajax is just a tool. My table saw cuts wood one way, my compound miter
saw another, my radial arm saw another. Technically, they can all do
the same cuts. It's just a lot nicer (and safer) to use a table saw to
rip panels and an SCMS to crosscut long lumber. And technically most of
what they can do can be done with a manual carpenter's saw and a bottle
of glucosomine.

Here's an example where Ajax is the better tool. I'm building a medical
application which has a desktop containing seven collapsible DIVs. Each
of those DIVs can also have at least two states: view and edit. Some
have three, with a result list (like a list of current insurance
policies). That's the way the client wanted it.

Necessarily, there are a lot of queries going on to populate all the
DIVs on that page: patient demographic info, insurance info, guarantor
info, family relations info, a list of historical referrals,
appointments, patient transportation, etc. So repopulating that page
sucks the air out of the database. If I correct a start date for an
insurance policy do I really want to repopulate that entire desktop
page? Heck no.

The better solution is to submit just the form that matters and update
just those DIVs where that update has data relevance. Mostly it's two
just queries instead of a dozen: put_foo and get_foo, with Ajax
arbitrating which display elements get updated.

[tedd]

Post by Steve Manes

Post by tedd
Now, what I am asking is not how ajax communication with the server
can be used, but rather is there anything beyond that which ajax
can provide?
Another way of asking this question is, "Besides not triggering a
refresh, what can ajax do that php can not?"

You're right: nothing. But just focusing on the get/post mechanics
as a baseline for comparison is kinda reducing the question to, "is
there anything client/server can do that client/server can't do?"
Ajax is just a tool. My table saw cuts wood one way, my compound
miter saw another, my radial arm saw another. Technically, they can
all do the same cuts. It's just a lot nicer (and safer) to use a
table saw to rip panels and an SCMS to crosscut long lumber. And
technically most of what they can do can be done with a manual
carpenter's saw and a bottle of glucosomine.
Here's an example where Ajax is the better tool. I'm building a
medical application which has a desktop containing seven collapsible
DIVs. Each of those DIVs can also have at least two states: view
and edit. Some have three, with a result list (like a list of
current insurance policies). That's the way the client wanted it.
Necessarily, there are a lot of queries going on to populate all the
DIVs on that page: patient demographic info, insurance info,
guarantor info, family relations info, a list of historical
referrals, appointments, patient transportation, etc. So
repopulating that page sucks the air out of the database. If I
correct a start date for an insurance policy do I really want to
repopulate that entire desktop page? Heck no.
The better solution is to submit just the form that matters and
update just those DIVs where that update has data relevance. Mostly
it's two just queries instead of a dozen: put_foo and get_foo, with
Ajax arbitrating which display elements get updated.

Oh, I get the reasons for using it. No arguments from me.

The beginning of this thread led me to suspect that someone had found
a way to move data from one browser window to another and I was
focusing in on that, but that turned to be false.

Cheers,

tedd

[John Campbell]

Post by tedd
The beginning of this thread led me to suspect that someone had found
a way to move data from one browser window to another and I was
focusing in on that, but that turned to be false.

What makes you think you can't move stuff from one window to another?
It is completely possible so long as everything is on the same domain.
There are ways of doing it across domains, but it is *much* more
complicated.

http://dev.gypsymaps.com/test/moveit.html

Enjoy,

-John Campbell

[tedd]

Post by John Campbell

Post by tedd
The beginning of this thread led me to suspect that someone had found
a way to move data from one browser window to another and I was
focusing in on that, but that turned to be false.

What makes you think you can't move stuff from one window to another?
It is completely possible so long as everything is on the same domain.
There are ways of doing it across domains, but it is *much* more
complicated.
http://dev.gypsymaps.com/test/moveit.html
Enjoy,
-John Campbell

-John:

I'm not talking about server-side to client-side sessions or cookies
communication, but client-side one browser window communication to
client-side another browser window (same client obviously).

For example, if you opened:

http://webbytedd.com/c/form-calc/

and started filling in the form. And then, you opened another browser
window and went to the same url, how could you get your second window
display all the data you entered in the first window?

If you know how, then I'm all ears.

Cheers,

tedd

[Kenneth Downs]

Post by John Campbell

Post by tedd
The beginning of this thread led me to suspect that someone had found
a way to move data from one browser window to another and I was
focusing in on that, but that turned to be false.

What makes you think you can't move stuff from one window to another?
It is completely possible so long as everything is on the same domain.
There are ways of doing it across domains, but it is *much* more
complicated.

There is a deeper user interface design issue here. Are you attempting
to ensure that if multiple windows are opened to the same table row,
that they will always hold the same information in real time? So that
if a user is editing in one, he will see the same information in the
other as he types?

If so, you are probably working too hard, a better user interface
concept is to trap a request for a duplicate view of the same
information and give focus to the window/tab that is already holding
it. A user will understand and expect this, and it is far simpler to
program.

This being said, the problem falls out like so:

IF WINDOWS ARE IN SAME SESSION, some mechanism must exist so that all
open windows/tabs are identifiable as holding a certain state, so that
you can give focus. If all you do is give focus, you are now finished.
If you want to keep the same information open in two windows, have fun,
you've got quite a bit of programming to do, and you better hire another
support person, you are going to get a lot of weird phone calls from the
users.

IF THE WINDOWS ARE NOT IN THE SAME SESSION, you have a bigger problem,
being of course there is no way to know what is going on. The simplest
case is to disallow multiple logins by a single user, then you prevent
this case altogether. If this is not an option, well...

[Gary Mort]

Post by tedd
I read your "simple example" and see that you can do it w/wo ajax --
but I don't see the advantage in using ajax other than presentation.

To do it without Ajax requires you to explicitly create code to track
each individual browser window as the user moves throughout the system
so you can bring them back to where they started from.

Using Ajax, you didn't have to write a line of code since the state was
maintained in the browser window itself.

So it was not having to code for the situation at all due to using Ajax.

Is that an advantage? I don't see it as one, as using Ajax in that
manner introduces other problems. But it is a different way to code and
based on your individual mindset, you might find it easier to think in
terms of letting the browser maintain it's own tracking than in trying
to track every variable yourself.

Post by tedd
Please correct me if I'm wrong, but isn't ajax (and ahah) only a means
to communicate with the server without causing a refresh? Does ajax
provide something beyond that?

Ajax changes the way you program.
Consider the following:
You have a form with 100 fields of information, 1 of which must be
unique in your database.

A user enters all 100 pieces of data and than submits it(yes, this is
poor form. You should pace the data over multiple input screens so as
not to overwhelm the user. I however deal with the real world where
real clients insist this is the way everyone wants to enter data and
refuse alternate suggestions such as tabs. *shrug*), you check for
uniqueness and generate an error message, as well as having to make sure
to preload every one of those 99 fields in the error form, as well as
prompting for a new unique key. Alternatively, you could prompt for
that one piece of unique data, and than reserve it for that user and
than prompt for the other 99.

Problems:
If checking after the user enters 100 different fields, they get very
very irate to be asked to enter yet another piece of data.
If you reserve the field for them and they don't complete the
registration, you also need to build a cleanup process or have phantom
records hanging around.

With Ajax:
You can check that unique field at the moment they enter it, so they can
pick one at the time. And you can check that field when they try to
submit it and keep them from submitting a non unique value(in case
someone claimed it while they filled in the info). You STILL need to
perform the final submit check, but you reduce user irritation by
minimizing attempts at loading bad data.

Also, the classic Ajax example. Go the newegg.com and start searching
for something. It generates a drop down list dynamically of potential
matches. Without AJAX and with a database of thousands of keywords, you
will need to perform fuzzy searches and deal with users mis-spelling
keywords.

With Ajax, you can get correct keywords and don't need fuzzy searches.

Ajax allows you to move certain lookups from popup windows, which are
annoying and frequently blocked, to the main window itself.

Imagine you want to select a user from a list of 1000 users. An old way
of doing it could be to list the letters of the Alphabet, and have
clicking on them popup a window with just the users who have a lastname
starting with that letter. Than you select the user and the popup
closes, using javascript to load the field.

With Ajax, instead you can do that sort of lookup in the browser itself.

All of this is due to being able to "communicate with the server without
causing a browser refresh" Basically, Ajax can turn traditional client
lite/server heavy applications into client heavy/server lite applications.

This is not always a good thing! It is simply a thing. Whether it is
good or bad depends strongly on your users, your application, and your
needs(I'm not a big Ajax advocate, heck I've only used it in a few apps.)

[tedd]

Post by Gary Mort

Post by tedd
Please correct me if I'm wrong, but isn't ajax (and ahah) only a
means to communicate with the server without causing a refresh?
Does ajax provide something beyond that?

You have a form with 100 fields of information, 1 of which must be
unique in your database.
-snip-
You can check that unique field at the moment they enter it, so they
can pick one at the time. And you can check that field when they
try to submit it and keep them from submitting a non unique value(in
case someone claimed it while they filled in the info). You STILL
need to perform the final submit check, but you reduce user
irritation by minimizing attempts at loading bad data.

Yes, I can still do that with just javascript and notify the user of
an incorrect entry immediately using onBlur. I do it all the time.

Post by Gary Mort
Also, the classic Ajax example. Go the newegg.com and start
searching for something. It generates a drop down list dynamically
of potential matches. Without AJAX and with a database of thousands
of keywords, you will need to perform fuzzy searches and deal with
users mis-spelling keywords.

Been there, done that and even have an example. But it is still
nothing more than communication between client/server without a
refresh.

Post by Gary Mort
With Ajax, you can get correct keywords and don't need fuzzy searches.

I can get specific or fuzzy searches with Ajax, but it is still just
communication.

Post by Gary Mort
Ajax allows you to move certain lookups from popup windows, which
are annoying and frequently blocked, to the main window itself.

Okay, this is where I'm missing the point. Are you saying that you
can have communication between windows on the client side? I would
like to see that.

Post by Gary Mort
Imagine you want to select a user from a list of 1000 users. An old
way of doing it could be to list the letters of the Alphabet, and
have clicking on them popup a window with just the users who have a
lastname starting with that letter. Than you select the user and
the popup closes, using javascript to load the field.
With Ajax, instead you can do that sort of lookup in the browser itself.
All of this is due to being able to "communicate with the server
without causing a browser refresh" Basically, Ajax can turn
traditional client lite/server heavy applications into client
heavy/server lite applications.

Now, I'm back to square one (I guess I should have read everything
before I started writing).

That's been my point -- ajax is only performing communication between
the server and the client without a refresh. I've been asking, is
that all there is?

Cheers,

tedd

[Kenneth Downs]

Post by Hans Zaunere

Post by Kenneth Downs
Ajax solves this problem neatly by letting you move all state [1] into
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
the UI.

I'm not sure what you mean, though, by keeping state in the browser.

For example, when a table maintenance form loads up (aka CRUD form),
with simulated tabs, one for browse, one for detail editing. There is a
global object that looks something like this:

x4global.tabs=new Object();
x4global.tabs[x0] = new Object();
x4global.tabs[x0].tabType = 'browse';
x4global.tabs[x0].table_id = 'contacts';
x4global.tabs[x0].columns = 'ssn,first_name,last_name,phone'
x4global.tabs[x0].widgets = new Object();
x4global.tabs[x0].widgets[ssn] = 'x4w_ssn'
x4global.tabs[x0].widgets[ssn] = 'x4w_ssn'
x4global.tabs[x0].widgets[ssn] = 'x4w_ssn'
...
... and so on

This allows the browser to keep a small library of JS code that receives
JSON back from the browser, then it looks at the response to see what it
should do, and uses the x4global object to figure out where to put things.
--
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com www.andromeda-project.org
631-689-7200 Fax: [phone]
cell: 631-379-0010

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070905/be368a1e/attachment.html>

[birgunj birgunj]

Dear All,

i need help in the following thing.

1. i am uploading ebooks on my website. i want to restrict user from downloading or printing the book.user should only read the document but cant not save or download or printing.
how do we do this ?

2.if any book have four author.one author text box ,i display but i want to display more if neccessary by clicking add author more.

or
how to add more choices by press CLTRL.

please help me its very urgent. i am very tense about this.

thanks to all in advance

humayoo





---------------------------------
Pinpoint customers who are looking for what you sell.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070906/4b979f10/attachment.html>

[Kenneth Downs]

Post by birgunj birgunj
Dear All,
i need help in the following thing.
1. i am uploading ebooks on my website. i want to restrict user from
downloading or printing the book.user should only read the document
but cant not save or download or printing.
how do we do this ?

This is called "DRM", for "Digital Rights Management" or "Digital
Restrictions Management", depending on your point of view.

The broad consensus is that it is not possible to do. The big record
labels have begun to abandon their efforts in this direction when it
comes to music, it just doesn't work.

However, if you must try, why not research the basic methods of DRM.

[Tim Lieberman]

Post by birgunj birgunj
Dear All,
i need help in the following thing.
1. i am uploading ebooks on my website. i want to restrict user from
downloading or printing the book.user should only read the document
but cant not save or download or printing.
how do we do this ?

Impossible, really. DRM just gets broken.

If making it difficult is "good enough" -- you could look for a eBook
system vendor that supports this in their viewer plug-in. Acrobat might
even have some features like this, but I really don't know.

You must be aware that no matter what system you use, someone will
probably break it, and there will be a hack available for anyone who's
motivated to find and use. So these systems are only useful if "make it
somewhat harder to save/print" is good enough.

Post by birgunj birgunj
2.if any book have four author.one author text box ,i display but i
want to display more if neccessary by clicking add author more.
or
how to add more choices by press CLTRL.

The best way is probably to use javascript to output new input tags that
look like:
<input name="authors[]" .../>

and limit the number displayed to four.

Then on the server, loop over $_REQUEST['authors'] and do something with
the data. Don't forget to repeat your limit of four on the server -- the
javascript limit is just for nice user experience... you must validate
the data on the server.

Post by birgunj birgunj
please help me its very urgent. i am very tense about this.
thanks to all in advance

Good luck!

[David Krings]

Post by birgunj birgunj
Dear All,
i need help in the following thing.
1. i am uploading ebooks on my website. i want to restrict user from
downloading or printing the book.user should only read the document but
cant not save or download or printing.
how do we do this ?
2.if any book have four author.one author text box ,i display but i want
to display more if neccessary by clicking add author more.
or
how to add more choices by press CLTRL.
please help me its very urgent. i am very tense about this.
thanks to all in advance
humayoo

If you do not want anyone to download or print the ebook you may need to
make it into a streaming video and even then it may not be that tricky
(just because I don't know how doesn't mean it is impossible).
We had this discussion here some days ago and you are basically out of
luck. In order for a user to read the ebook they have to download it to
their PC to be displayed in a browser. This is how WWW works. And once
it is displayed in the browser you may have some control over the
context menu, but I doubt you can manage the browser's main menues. And
that is where the Print command is located. Also, if the users have some
clue as to how WWW works, they will locate the downloaded ebook in the
browser cache folder. Although, there are some ways to force the browser
not to cache the page contents. But then, how do you implement the
ebook in a page anyway? Do you have something that obfuscates the
original location on the server? Otherwise the user just needs to look
at the page source and go directly to the URL of the ebook - and then,
voila, no code involved that could control caching.
I could go on and on, but you really try to solve a marketing or
management problem by wildly throwing technology at it. That approach is
destined to fail!
Here is my proposal that from my own experience works much better:
a) price your offering so that there is no point in breaking the law
b) have your offering to be of such a high quality in content and
delivery that users do want to pay you
c) add some other form of authentication to your site so that one has to
login first or do something special that will make it more difficult for
non-registered users to get the content

And if a), b), and c) are not an option, don't put it on the web. Put a
request form up and mail CDs that are fully DRM enabled and
self-destruct upon first use. Talk to Microsoft about this, they are
experts in this asanine behavior.

For number 2: get a book about HTML and PHP and create some forms with
code that first asks for the number of authors and then provides a form
that as sufficient author entry fields.
Or get a book about ECMAScript and do some of this more fancy stuff
where you process the click of a "More..." button on the client side. I
am sure there are some on this list who could help you, but since this
is a PHP list and we do server side scripting you are in the wrong
concert here.


David

[PaulCheung]

Hi Humayoo,

Try Googling on "PHP Data Security" or "Data Security Software". I hope this is of some help.
I am sorry if I cannot help with any coding as my PHP/MySQL is not good enough.

Paul

----- Original Message -----
From: birgunj birgunj
To: NYPHP Talk
Sent: Thursday, September 06, 2007 11:33 AM
Subject: [nycphp-talk] neeed help


Dear All,

i need help in the following thing.

1. i am uploading ebooks on my website. i want to restrict user from downloading or printing the book.user should only read the document but cant not save or download or printing.
how do we do this ?

2.if any book have four author.one author text box ,i display but i want to display more if neccessary by clicking add author more.

or
how to add more choices by press CLTRL.

please help me its very urgent. i am very tense about this.

thanks to all in advance

humayoo





------------------------------------------------------------------------------
Pinpoint customers who are looking for what you sell.


------------------------------------------------------------------------------


_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com

Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070906/baba13df/attachment.html>

[Elliotte Harold]

Post by Kenneth Downs
One thing that seems to have gone unsaid in the praise for Ajax is its
ability to radically transform how we maintain state.
The web server session is our basic mechanism for storing information
between requests. But it gets clumsier and clumsier to try to maintain
complex state across many page requests when you use a session.
Ingenious minds have put their will to the problem and come up with
workable systems, but all of them are complicated because of the nature
of the problem.

There are no sessions, or at least there shouldn't be in well-designed
Web applications. There's resource state (on the server) and there's
application state (on the client). It sounds like you're in the process
of reinventing REST. In particular you've noticed that keeping
application state on the server is a royal pain that severely limits
scalability.

However this has been known for a long time. Indeed one of the primary
design principles of HTTP is that application state is not stored on the
server but is transmitted with each request. This was true long before
AJAX or even JavaScript. Usually the appropriate place to put such
application state is in the URL, though sometimes what we initially
think of as application state can be recast as resource state.

Post by Kenneth Downs
That problem, stated here, is simply the problem of tracking what I'll
call the "context" of a user's session. Some elements of a session are
fixed: the user id, the password, a few other things, but almost
everything that we need to track is always changing. A basic example: a
list of search results. Where do you store it? When the user hits,
"NEXT PAGE", how do you know what to do? If you are using a session,
what happens if he opens a new window and has two search results sets up
for two different tables?

Which is exactly why we don't use sessions for such applications.
Instead the page of "next" search results is a URL like

http://www.google.com/search?q=Ken+Downs&hl=en&start=10&sa=N

That's an actual Google "Next" URL. It still works even though I've
pasted it into an e-mail and sent it to you, thus breaking any notion of
session.

Post by Kenneth Downs
Ajax solves this problem neatly by letting you move all state [1] into
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed, the
UI.
I've been converting the basic Andromeda UI code over to a completely
AJAX system [1], and have found my code radically simplified and far
smoother, due almost entirely to the moving of all state information to
the browser. Hurray for Ajax!

Hurray for REST! AJAX or no AJAX, this is the right way to design a web
application. There's a really excellent book out now from O'Reilly
called "RESTful Web Services" that covers this in detail.

Post by Kenneth Downs
[1] Here I'll use "state" to mean the changing context of user requests,
and assume we are still using the session for User_id and password.

You still have a problem then, though perhaps your systems haven't yet
grown big enough to have noticed it. But it will kill you when you need
to scale beyond one server. The authentication info needs to be
transmitted with each request also.

[Kenneth Downs]

Post by Elliotte Harold
Which is exactly why we don't use sessions for such applications.
Instead the page of "next" search results is a URL like
http://www.google.com/search?q=Ken+Downs&hl=en&start=10&sa=N

Did you log into Google?

[Elliotte Harold]

Post by Kenneth Downs

Post by Elliotte Harold
Which is exactly why we don't use sessions for such applications.
Instead the page of "next" search results is a URL like
http://www.google.com/search?q=Ken+Downs&hl=en&start=10&sa=N

Did you log into Google?

Checking the screen it looks I was logged in, but that doesn't change
the URL here. Follow that URL and you get the same results I do.

[Kenneth Downs]

Post by Elliotte Harold

Post by Kenneth Downs

Post by Elliotte Harold
Which is exactly why we don't use sessions for such applications.
Instead the page of "next" search results is a URL like
http://www.google.com/search?q=Ken+Downs&hl=en&start=10&sa=N

Did you log into Google?

Checking the screen it looks I was logged in, but that doesn't change
the URL here. Follow that URL and you get the same results I do.

Should I email you a link allowing you to log into my customer's
application and view confidential medical information?

[Elliotte Harold]

Post by Kenneth Downs
Should I email you a link allowing you to log into my customer's
application and view confidential medical information?

User authentication is (usually) separate from the URL. You can e-mail
me such a link if you wish, but without the username and password I
wouldn't get in.

Nonetheless, the username and password should be transmitted with each
request (in the HTTP header, not the URL) so that it doesn't matter
whether I've switched browsers, rebooted my machine, or told my office
manager to login under my name on her PC.

The resource is identified by a URL and nothing but a URL. Whether I am
allowed to load that URL is a separate issue.

This is one point a lot of otherwise RESTful services like Amazon's E3
get wrong. My mailbox should have a URL like
https://mail.google.com/mail/erharold and yours should have a URL like
https://mail.google.com/mail/kdowns. Nonetheless, merely knowing the URL
would not be sufficient to log either of us in to either mailbox.

[Kenneth Downs]

Post by Elliotte Harold

Post by Kenneth Downs
Should I email you a link allowing you to log into my customer's
application and view confidential medical information?

Nonetheless, the username and password should be transmitted with each
request (in the HTTP header, not the URL) so that it doesn't matter
whether I've switched browsers, rebooted my machine, or told my office
manager to login under my name on her PC.

That can only be done if the password is stored on the browser between
requests. No thanks!

At any rate, in principle I believe that sessions are a bad way to do
things, they just have that bag-on-the-side feel. The only permanent
use of a session in Andromeda is to store user information, notably
user_id and password. I do this only because I am not aware of a secure
session-less alternative. Any ideas are welcome.

[bz-gmort]

Post by Kenneth Downs
That can only be done if the password is stored on the browser between
requests. No thanks!
At any rate, in principle I believe that sessions are a bad way to do
things, they just have that bag-on-the-side feel. The only permanent
use of a session in Andromeda is to store user information, notably
user_id and password.

Why do you need to store the password?

Once the user has authenticated, their authenticated. You don't need to
keep a password lying around past that point unless you want to make
them re-authenticate each time they access some data. And since your
storing that information on the server, it's somewhat irrelevant to
store it since your already trusting whatever other mechanisms you have
between the user and the server.

Though I would point out that with browsers these days, that password is
gonna be stored on the browser no matter what you do short of embedding
a flash or java applet to process the logon. They save so much
information, the user might have to explicitly confirm saving the
address, but it will be saved.

[Kenneth Downs]

Post by bz-gmort

Post by Kenneth Downs
That can only be done if the password is stored on the browser
between requests. No thanks!
At any rate, in principle I believe that sessions are a bad way to do
things, they just have that bag-on-the-side feel. The only permanent
use of a session in Andromeda is to store user information, notably
user_id and password.

Why do you need to store the password?
Once the user has authenticated, their authenticated. You don't need
to keep a password lying around past that point unless you want to
make them re-authenticate each time they access some data. And since
your storing that information on the server, it's somewhat irrelevant
to store it since your already trusting whatever other mechanisms you
have between the user and the server.

Database access. Each trip to the server requires that you make a
connection to the server.

In the PHP+MySQL world it is taken as an article of faith that you
connect to the database as a super-user or admin, and your application
code handles security. But not everybody thinks this way.

That approach has many problems in a large-table-count system, including
but not limited to documentation of security policies, effectiveness,
efficiency, and scalability. Probably the the most significant problem
is that you cannot provide your customer's IT departments with true
access to the database, which is a requirement to get some jobs.

As part of an overall more secure architecture, we connect the user to
the database with a real database account, the database server is in
charge of security and the program code has nothing to do with it. In
fact, the program by itself has no ability to connect to the database
unless given credentials by a user. This solves many problems, but it
does require us to keep track of the user's password once they've given
it to us, so that we can connect to the database on each of their
requests.

Hence my only use of a session.

Post by bz-gmort
Though I would point out that with browsers these days, that password
is gonna be stored on the browser no matter what you do short of
embedding a flash or java applet to process the logon. They save so
much information, the user might have to explicitly confirm saving the
address, but it will be saved.

True, you cannot stop the various "wallet" mechanisms from storing it
<Sigh>. But at least I did not add yet another :/

[bz-gmort]

Post by bz-gmort
Why do you need to store the password?

<snip>
Database access. Each trip to the server requires that you make a
connection to the server.
In the PHP+MySQL world it is taken as an article of faith that you
connect to the database as a super-user or admin, and your application
code handles security. But not everybody thinks this way.

Thanks. That was the only reason I could think of(not MySQL actually,
but any external system you need the php script to authenticate too and
want to manage security in that external system at a user level).

Though I would argue that is standard to use a single userid/password
for all connections, not that it is the admin or super user.

I would be tempted towards using some sort of token generated
authentication scheme instead, so instead of saving a userid and
password in the session you save a token. But I'm not quite sure to
what levels MySQL has advanced DB wise, and not every third party app
will support an alternate authentication mechanism. And in the end, if
it works, why bother?

[Elliotte Harold]

Post by Kenneth Downs
That can only be done if the password is stored on the browser between
requests. No thanks!

I don't know about your browser but mine (and those of most of the
people I know) store lots of passwords pretty much all the time. I
prefer to trust Firefox's encryption and security to my ability to
remember umpteen different passwords.

Post by Kenneth Downs
At any rate, in principle I believe that sessions are a bad way to do
things, they just have that bag-on-the-side feel. The only permanent
use of a session in Andromeda is to store user information, notably
user_id and password. I do this only because I am not aware of a secure
session-less alternative. Any ideas are welcome.

The key idea is that all authentication data is transmitted with each
request, not merely a session token. There may well be ways to make that
authentication data something other than a username and password.

You may wish to explore what Amazon E3 does. They have some sort of
unique private-key/public key encryption scheme that might suit you.
Google GData also has some sort of strange, custom authentication scheme
though I haven't explored it in detail.

[Kenneth Downs]

Post by Elliotte Harold

Post by Kenneth Downs
That can only be done if the password is stored on the browser
between requests. No thanks!

I don't know about your browser but mine (and those of most of the
people I know) store lots of passwords pretty much all the time. I
prefer to trust Firefox's encryption and security to my ability to
remember umpteen different passwords.

Me too, except that my customers still run IE on Windows.

Post by Elliotte Harold

Post by Kenneth Downs
At any rate, in principle I believe that sessions are a bad way to do
things, they just have that bag-on-the-side feel. The only permanent
use of a session in Andromeda is to store user information, notably
user_id and password. I do this only because I am not aware of a
secure session-less alternative. Any ideas are welcome.

You may wish to explore what Amazon E3 does. They have some sort of
unique private-key/public key encryption scheme that might suit you.
Google GData also has some sort of strange, custom authentication
scheme though I haven't explored it in detail.

You can issue them a key as well, and require that key. That adds
trouble to the login process, but does produce greater security.

[Daniel Convissor]

Post by Elliotte Harold
Nonetheless, the username and password should be transmitted with each
request (in the HTTP header, not the URL)

Are you saying the web browser should send the user name and password to
the HTTP server on each request? That's a lousy idea.

Post by Elliotte Harold
so that it doesn't matter
whether I've switched browsers, rebooted my machine, or told my office
manager to login under my name on her PC.

How.

--Dan

[Elliotte Harold]

Post by Daniel Convissor

Post by Elliotte Harold
Nonetheless, the username and password should be transmitted with each
request (in the HTTP header, not the URL)

Are you saying the web browser should send the user name and password to
the HTTP server on each request? That's a lousy idea.

Yes I am, and it's not a lousy idea. This follows directly from the
core principles of HTTP. HTTP Basic authentication does that. HTTP
digest is a little more complex. And there are some other alternatives.
However the fundamental principle is that full auth data must be sent
with each request.

Breaking that rule is going to cost you big time when you need to scale
an application. It very well may introduce single points of failure into
your app. You can architect around those, but only at the cost of doing
a lot more work with a lot more machines than you would have had to do
if your app had followed the design of HTTP instead of working against it.

[Kenneth Downs]

Post by Elliotte Harold

Post by Daniel Convissor

Post by Elliotte Harold
Nonetheless, the username and password should be transmitted with
each request (in the HTTP header, not the URL)

Are you saying the web browser should send the user name and password
to the HTTP server on each request? That's a lousy idea.

Yes I am, and it's not a lousy idea. This follows directly from the
core principles of HTTP. HTTP Basic authentication does that. HTTP
digest is a little more complex. And there are some other
alternatives. However the fundamental principle is that full auth data
must be sent with each request.
Breaking that rule is going to cost you big time when you need to
scale an application. It very well may introduce single points of
failure into your app. You can architect around those, but only at the
cost of doing a lot more work with a lot more machines than you would
have had to do if your app had followed the design of HTTP instead of
working against it.

It is actually very appealing from the overall design viewpoint. Since
Andromeda logs you in to db server with the credentials you supply
(instead of something generic) then we have lost all need for state.

The itch though is in entrusting the uid/pw to the browser's memory,
which is easily exploitable. I simply cannot believe that that data is
adequately protected on an IE/Windows machine.

But then on the third hand the browser is trapping passwords anyway with
various wallet mechanisms that I cannot prevent, so what the heck, right?

Right now I'm considering the judgment call between those two ideas.

[Daniel Convissor]

Post by Elliotte Harold
However the fundamental principle is that full auth data must be sent
with each request.
Breaking that rule is going to cost you big time when you need to scale
an application.

Basic and Digest auth are slow when it comes to dealing with large user
bases. They also increase insecurity, particularly when working over
non-encrypted connections. Plus I don't like the idea of keeping
authentication information in the browser.

Sure, session id's introduce security pitfalls such as session hijacking,
but that seems less ominous to me than giving out your user name and
password on each request.

Post by Elliotte Harold
It very well may introduce single points of failure into
your app. You can architect around those, but only at the cost of doing
a lot more work with a lot more machines than you would have had to do
if your app had followed the design of HTTP instead of working against it.

How is using a session id cookie "working against" the design of HTTP?

--Dan

[Elliotte Harold]

Post by Daniel Convissor
Basic and Digest auth are slow when it comes to dealing with large user
bases.

I've seen no evidence of that whatsoever.

Post by Daniel Convissor
They also increase insecurity, particularly when working over
non-encrypted connections.

For basic I'd use encrypted connections only. Digest is fine in the
"clear".

Post by Daniel Convissor
Plus I don't like the idea of keeping
authentication information in the browser.

Tough. That's being done anyway.

Post by Daniel Convissor
Sure, session id's introduce security pitfalls such as session hijacking,
but that seems less ominous to me than giving out your user name and
password on each request.

Only basic really gives out user name and password info one each
request. Digest never passes the password at all. And there are other
schemes.

Post by Daniel Convissor

Post by Elliotte Harold
It very well may introduce single points of failure into
your app. You can architect around those, but only at the cost of doing
a lot more work with a lot more machines than you would have had to do
if your app had followed the design of HTTP instead of working against it.

How is using a session id cookie "working against" the design of HTTP?

Because HTTP is explicitly designed to be stateless and sessionless.
See, for example, Sam Ruby's RESTful Web Services.

[Kenneth Downs]

Post by Elliotte Harold

Plus I don't like the idea of keeping authentication information in
the browser.

Tough. That's being done anyway.

True, but we need a better answer than that.

Can you explain what mechanisms are storing the passwords, and why no
additional weakness has been introduced?

[Elliotte Harold]

Post by Kenneth Downs
True, but we need a better answer than that.
Can you explain what mechanisms are storing the passwords, and why no
additional weakness has been introduced?

The issue here is really one of psychology and usability. A poorly
usable authentication system will cause users to route around it, for
example by always using the same password, by choosing easily remembered
passwords, by writing them down on Post-it notes stuck to their
monitors, or all of the above. The theoretical strength of
authentication systems is irrelevant in the face of user
counter-measures such as these.

Only systems that take users into account will be secure in the real
world. Usability is not a sufficient condition for secure
authentication, but it is a necessary one.

Given the wealth of passwords users are expected to remember in order to
participate in the Web, the only plausibly usable system for managing
client password lists that maintains some level of security is single
sign-on. Server-based single sign-on systems have failed because no
standard centralized repository has been established. Thus the only
choice is to place this repository on the client. (I suspect that would
still be the right answer even if one of the server based systems had
succeeded, but the point is moot because none did.)

The vast majority of users will only accept such a system if it is
actually easier to use than pen and paper. The only such system is the
one that doesn't require the user to do any extra work. That means the
browser itself (or a plug-in integrated into the browser) remembers the
password.

EVERYTHING ELSE THAT HAS BEEN TRIED TO DATE HAS FAILED. NO EXCEPTIONS.

Now assuming you're willing to work under those constraints, you can
make the browser repository a little stronger. You can use better
encryption for the password store. You can make sure that the memory
area in which the browser stores its passwords is promptly zeroed out
after use. And you can play a few other tricks that don't affect the
user experience. But that's about it.

A browser-based password store is the most secure authentication system
devised to date. In practice, everything else that has been tried has
been less secure. I suspect we're not going to improve on this state of
affairs until we move away from usernames and passwords completely.

[Daniel Convissor]

Post by Elliotte Harold
Thus the only
choice is to place this repository on the client.
... snip ...
That means the
browser itself (or a plug-in integrated into the browser) remembers the
password.
EVERYTHING ELSE THAT HAS BEEN TRIED TO DATE HAS FAILED. NO EXCEPTIONS.

Except having a password store on one's computer that's separate from the
browser. There are several pieces of software that do this.

My technique is to store password information in a GPG encrypted text
file. Of course, this isn't a technique the masses would be able to
handle.

Post by Elliotte Harold
A browser-based password store is the most secure authentication system
devised to date.

No, it's not.

We're really diverging from PHP here, so this is the last posting I'll
make in this thread.

--Dan

[Elliotte Harold]

Post by Daniel Convissor
Except having a password store on one's computer that's separate from the
browser. There are several pieces of software that do this.

If that's integrated with the browser, sure. However if it's not, it's
too complicated. Opening a separate app, typing in its password, then
copying and pasting the username and password into the browser is too
much trouble.

Even Bruce Schneier, inventor of PasswordSafe among other things, stores
his passwords on a little piece of paper in his wallet!

http://www.theregister.co.uk/2005/07/19/password_schneier/

I reiterate: browser-based password stores are the most secure solution
yet devised.

[Kenneth Downs]

Post by Elliotte Harold

Post by Kenneth Downs
True, but we need a better answer than that.
Can you explain what mechanisms are storing the passwords, and why no
additional weakness has been introduced?

The issue here is really one of psychology and usability. A poorly
usable authentication system will cause users to route around it, for
example by always using the same password, by choosing easily
remembered passwords, by writing them down on Post-it notes stuck to
their monitors, or all of the above. The theoretical strength of
authentication systems is irrelevant in the face of user
counter-measures such as these.

<snip>

Post by Elliotte Harold
A browser-based password store is the most secure authentication
system devised to date. In practice, everything else that has been
tried has been less secure. I suspect we're not going to improve on
this state of affairs until we move away from usernames and passwords
completely.

Well you've convinced me.

Technically there is nothing really to the issue of changing the PHP code.

However, this leaves the issue of what we are telling customers, if
anything.

The conversation we ought to have with the customer is all about what
type of single sign-on the users are using. But, methinks most
programmers instead are having a conversation about their own efforts in
handling passwords, which is misleading and irrelevant.

[Daniel Convissor]

Post by Elliotte Harold
For basic I'd use encrypted connections only. Digest is fine in the
"clear".

No HTTP auth method is okay in the clear. Digest sends an MD5 hash as
the token. While that doesn't tell me what your password is, unless I
figure it out via a reverse lookup database, I can just forge my request
headers to include the hash itself.

Post by Elliotte Harold

Post by Daniel Convissor
Plus I don't like the idea of keeping
authentication information in the browser.

Tough. That's being done anyway.

Depends on what the user's settings are.

Post by Elliotte Harold

Post by Daniel Convissor
How is using a session id cookie "working against" the design of HTTP?

Because HTTP is explicitly designed to be stateless and sessionless.
See, for example, Sam Ruby's RESTful Web Services.

Passing your user name and password on each request is no different than
passing a session ID on each request. They both indicate who you are.

--Dan

[Rob Marscher]

Post by Elliotte Harold

Post by Kenneth Downs

Post by Elliotte Harold
http://www.google.com/search?q=Ken+Downs&hl=en&start=10&sa=N

Did you log into Google?

Checking the screen it looks I was logged in

So... how did Google know you were logged in? Look at your cookies
-- there's one from google.com called SID -- Session ID!

Google is using sessions to keep track of whether or not you are
logged in. I see authentication as the primary use for sessions. I
agree that sessions could be considered evil if you try to store too
much in there and rely on them for parts of your application that
could be stored elsewhere. For authentication purposes, I don't see
another alternative, unless what I consider "sessions" is different
from your definition.

In terms of large scaling, you could have a federation of session
servers using a hashing algorithm based on the session id to
determine which sessions are stored on which server and have the rest
of your app communicate with them to determine if the session is
valid and get a user id and authentication credentials. I do agree
that they are difficult to scale because of high read and write
concurrency. I would imagine that all the huge apps use a memory
cache for sessions and optionally write them to disk periodically or
log them in some other way if they need to keep track of stats or
it's critical that no one's session can be lost by a server reboot.

-Rob

[David Krings]

Post by Elliotte Harold
Which is exactly why we don't use sessions for such applications.
Instead the page of "next" search results is a URL like
http://www.google.com/search?q=Ken+Downs&hl=en&start=10&sa=N
That's an actual Google "Next" URL. It still works even though I've
pasted it into an e-mail and sent it to you, thus breaking any notion of
session.

But isn't that the old GET that has so many limitations that many web
app design guides basically tell you not to use it?
And it depends on what you transfer in clear text as URL parameters. A
Google search is probably OK, but what if your application is about
sensitive data? You then need to craft identifiers that are dropped
after first use and never used again or some other untraceable
obfuscating mechanism.

There was also the point made of scalability. As in this example, the
search results are not stored anywhere, but get recreated each time a
request is sent. That pushes the scalability issue from the web server
to the database server, where it may or may not be handled more efficiently.

I do understand the limitation of sessions as well, which I wasn't
really aware of before.

To sum it up: It sucks! One round of applause for the fat client who
throws the strict client/server design principles out the window.


David

[Elliotte Harold]

Post by David Krings
But isn't that the old GET that has so many limitations that many web
app design guides basically tell you not to use it?

I have no idea what you're talking about. GET is GET. There's no old GET
and new GET that I've ever heard of.

It's certainly true that there are a lot of bad web app design guides
out there. Most of them try to reinvent client server on the web.
They're like a manual for plastic molding machines that pretends the
molder is really just a funny kind of table saw and drill press. Follow
their directions and you'll develop problematic, unscalable
applications; and certainly lots of people do.

Post by David Krings
And it depends on what you transfer in clear text as URL parameters. A
Google search is probably OK, but what if your application is about
sensitive data? You then need to craft identifiers that are dropped
after first use and never used again or some other untraceable
obfuscating mechanism.

No. You use HTTPS.

Post by David Krings
There was also the point made of scalability. As in this example, the
search results are not stored anywhere, but get recreated each time a
request is sent. That pushes the scalability issue from the web server
to the database server, where it may or may not be handled more efficiently.

In point of fact, Google uses probably millions (maybe hundreds of
thousands but I expect millions) of servers. They need this massive
horizontal scalability. To make that work you really need to not care
which server processes any given request. Three subsequent requests can
and usually do go to three different physical servers. The more session
state you try to maintain the harder that is to handle.

By contrast, if you design apps so they don't need session state, then
you can scale horizontally very easily and you need a lot fewer actual
servers.

[David Krings]

Post by Elliotte Harold

Post by David Krings
But isn't that the old GET that has so many limitations that many web
app design guides basically tell you not to use it?

I have no idea what you're talking about. GET is GET. There's no old GET
and new GET that I've ever heard of.

Bad wording on my part. The talk went from states and sessions and
whathavenot to the Google URL example, which is nothing more than
passing form info via GET. It came across as this is a great new way of
solving the discussed issue, which indeed it isn't as it is a plain GET
mechanism that is around for ages.

Post by Elliotte Harold
It's certainly true that there are a lot of bad web app design guides
out there. Most of them try to reinvent client server on the web.

Uhm, isn't browser and server the purest form of client server? The
server doesn't to crap without the client constantly asking for it.
There are ways to improve that with AJAX or server side scripting like
PHP or a combination of both (which is needed when using databases as
the client cannot connect to the db server directly).
I wouldn't necessarily call the design guides all bad, but they are for
sure different.

Post by Elliotte Harold
They're like a manual for plastic molding machines that pretends the
molder is really just a funny kind of table saw and drill press. Follow
their directions and you'll develop problematic, unscalable
applications; and certainly lots of people do.

Which begs the question if every app developed needs to be scalable. If
there are at any given point in time no more than a few dozen clients
connecting scalability isn't an issue. So it depends. For the low
client, one site app I find sessions extremely useful.

Post by Elliotte Harold

Post by David Krings
And it depends on what you transfer in clear text as URL parameters. A
Google search is probably OK, but what if your application is about
sensitive data? You then need to craft identifiers that are dropped
after first use and never used again or some other untraceable
obfuscating mechanism.

No. You use HTTPS.

Understood....bit with all that security discussion, it is funny that
nobody focuses any effort on securing keyboards, mice, and monitors.
Many tests have shown that you don't need a password cracker, but just
some cheap equipment from Radioshack to record signals coming from input
devices. That just as a side note.

Post by Elliotte Harold

Post by David Krings
There was also the point made of scalability. As in this example, the
search results are not stored anywhere, but get recreated each time a
request is sent. That pushes the scalability issue from the web server
to the database server, where it may or may not be handled more efficiently.

In point of fact, Google uses probably millions (maybe hundreds of
thousands but I expect millions) of servers. They need this massive
horizontal scalability. To make that work you really need to not care
which server processes any given request. Three subsequent requests can
and usually do go to three different physical servers. The more session
state you try to maintain the harder that is to handle.
By contrast, if you design apps so they don't need session state, then
you can scale horizontally very easily and you need a lot fewer actual
servers.

Understood as well...which is why Google and the likes drop sometimes
massive cookies on the client side. That addresses the scalability
issue, but is from a security standpoint somewhat questionable, which
again in case of a Google search is likely a non-issue. This is why I
routinely dump all cookies except for a few that I know I want to keep
for convenience.

David

[Urb LeJeune]

I'm looking to do a mouse over menu. You run the mouse over a main item
and a submenu appears, if available. I would prefer a css implementation
although a Java Script application would be acceptable.

Does anyone have any experience with such an animal or willing to make
a suggestions.

Thanks

Urb

Dr. Urban A. LeJeune, President
E-Government.com
800-204-9545

[Jon Baer]

Suckerfish ...

http://www.alistapart.com/articles/dropdowns/
http://www.htmldog.com/articles/suckerfish/dropdowns/

- Jon

Post by Urb LeJeune
I'm looking to do a mouse over menu. You run the mouse over a main item
and a submenu appears, if available. I would prefer a css
implementation
although a Java Script application would be acceptable.
Does anyone have any experience with such an animal or willing to make
a suggestions.
Thanks
Urb
Dr. Urban A. LeJeune, President
E-Government.com
800-204-9545
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070907/41be6110/attachment.html>

[tedd]

Post by Urb LeJeune
I'm looking to do a mouse over menu. You run the mouse over a main item
and a submenu appears, if available. I would prefer a css implementation
although a Java Script application would be acceptable.
Does anyone have any experience with such an animal or willing to make
a suggestions.
Thanks
Urb
Dr. Urban A. LeJeune, President
E-Government.com
800-204-9545

Try these -- they are widely used and work great:

http://sperling.com/examples/menuh/

http://sperling.com/examples/menuv/

However, they do use a js routine to make it work for IE browsers
else IE won't work.

You might review cssplay -- I've seen that they have a pure css menu
there, but it uses a table -- if that matters to you -- and -- it's a
bit more complicated and verbose. BUT, it works without js.

Cheers,

tedd

[Rick Retzko]

Hi - Take a look at 'Stylin' with CSS' (Charles Wyke-Smith), he devotes
about 20 pages to building exactly this without any javascript including the
hacks necessary for IE. A bit tricky, but it works. The book is very
functional if you're just getting past the basics.

You can also download the script from his www.bbd.com/stylin site.


Best Regards -

Rick
============
MFR Holdings, LLC
rick at click-rick.net
201.755.4083

-----Original Message-----
From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On
Behalf Of Urb LeJeune
Sent: Friday, September 07, 2007 10:11 PM
To: NYPHP Talk
Subject: [nycphp-talk] Mouse Over Menu

I'm looking to do a mouse over menu. You run the mouse over a main item and
a submenu appears, if available. I would prefer a css implementation
although a Java Script application would be acceptable.

Does anyone have any experience with such an animal or willing to make a
suggestions.

Thanks

Urb

Dr. Urban A. LeJeune, President
E-Government.com
800-204-9545


_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com

Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php

[Jason Sia]

Hi,
You could try the hover effect but for Internet Explorer you should add a behavior (download csshover.htc) to make hover work in IE . You should use <li> for this.

----- Original Message ----
From: Urb LeJeune <urb at e-government.com>
To: NYPHP Talk <talk at lists.nyphp.org>
Sent: Saturday, September 8, 2007 10:11:22 AM
Subject: [nycphp-talk] Mouse Over Menu

I'm looking to do a mouse over menu. You run the mouse over a main item
and a submenu appears, if available. I would prefer a css implementation
although a Java Script application would be acceptable.

Does anyone have any experience with such an animal or willing to make
a suggestions.

Thanks

Urb

Dr. Urban A. LeJeune, President
E-Government.com
800-204-9545


_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com

Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php






Send instant messages to your online friends http://uk.messenger.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070907/7cda1854/attachment.html>

[selyah]

Hello ;
I am in the process of completing a very complex php script and need to add a special effect using html. The effect that i have to do is a simple roll over images and upon each roll over with the mouse the images increase in size and then return back to the original size. The problem is that i am sure that this involves javascript and that is my weak point.
Therefore, i am asking anyone who can assist with a sample code or know of a link that would be helpful.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070907/fcc2fc2b/attachment.html>

[Jon Baer]

Probably the best way Ive seen it implemented (and easiest) would be
to use the Fisheye plugin for jQuery ...

http://www.ndesign-studio.com/demo/css-dock-menu/css-dock.html

* Download link (jQuery): http://docs.jquery.com/
Downloading_jQuery#Current_Release
* Download link (Fisheye): http://interface.eyecon.ro/download

(Although the SVN copy of jQuery might have the latest version of
this plugin - not 100% sure)

- Jon

Post by selyah
Hello ;
I am in the process of completing a very complex php script and
need to add a special effect using html. The effect that i have to
do is a simple roll over images and upon each roll over with the
mouse the images increase in size and then return back to the
original size. The problem is that i am sure that this involves
javascript and that is my weak point.
Therefore, i am asking anyone who can assist with a sample code or
know of a link that would be helpful.
Thanks
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070908/29b10f10/attachment.html>

[tedd]

Post by selyah
Hello ;
I am in the process of completing a very complex php script and
need to add a special effect using html. The effect that i have to
do is a simple roll over images and upon each roll over with the
mouse the images increase in size and then return back to the
original size. The problem is that i am sure that this involves
javascript and that is my weak point.
Therefore, i am asking anyone who can assist with a sample code or
know of a link that would be helpful.
Thanks

selyah:

Here an example of an enlarging roll-over using only css with no javascript.

http://webbytedd.com/bb/replace-image2/

If that's what you want, everything's there.

Cheers,

tedd

[Edgar Reyes]

Here is a simple way to do a roll over effect for images;

<a href="#" onMouseOver='rollover.src="images/lagerimage.jpg"'
onMouseOut='rollover.src="images/smallimage.jpg"'>
<img src="images/smallimage.jpg" name="rollover" border="0"></a>

ER

-----Original Message-----
From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On
Behalf Of tedd
Sent: Saturday, September 08, 2007 11:53 AM
To: NYPHP Talk
Subject: Re: [nycphp-talk] Roll ove image

Post by selyah
Hello ;
I am in the process of completing a very complex php script and
need to add a special effect using html. The effect that i have to
do is a simple roll over images and upon each roll over with the
mouse the images increase in size and then return back to the
original size. The problem is that i am sure that this involves
javascript and that is my weak point.
Therefore, i am asking anyone who can assist with a sample code or
know of a link that would be helpful.
Thanks

selyah:

Here an example of an enlarging roll-over using only css with no javascript.

http://webbytedd.com/bb/replace-image2/

If that's what you want, everything's there.

Cheers,

tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com

Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php

[Jason Sia]

Hi,
You can create function like this:
<script>
function Enlarge() //enlarge the image
{
document.getElementById('image').style.width=??;
document.getElementById('image').style.height=??;
}
function Reduce() //reduce the image
{
document.getElementById('image').style.width=??;
document.getElementById('image').style.height=??;
}
</script>

<html>
<body>
<img id='image' style='width:xx;height:xx;' src='' onmouseover="Enlarge();" onmouseout="Reduce();">
</body>
</html>

Be sure to have an image with a good resolution so that it does not pixelize when you enlarge it

----- Original Message ----
From: selyah <selyah1 at yahoo.com>
To: NYPHP Talk <talk at lists.nyphp.org>
Sent: Saturday, September 8, 2007 1:12:55 PM
Subject: [nycphp-talk] Roll ove image

Hello ;
I am in the process of completing a very complex php script and need to add a special effect using html. The effect that i have to do is a simple roll over images and upon each roll over with the mouse the images increase in size and then return back to the original size. The problem is that i am sure that this involves javascript and that is my weak point.
Therefore, i am asking anyone who can assist with a sample code or know of a link that would be helpful.
Thanks





Send instant messages to your online friends http://uk.messenger.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070907/b8238489/attachment.html>

[selyah]

thank you

Jason Sia <jsia18 at yahoo.com> wrote: Hi,
You can create function like this:
<script>
function Enlarge() //enlarge the image
{
document.getElementById('image').style.width=??;
document.getElementById('image').style.height=??;
}
function Reduce() //reduce the image
{
document.getElementById('image').style.width=??;
document.getElementById('image').style.height=??;
}
</script>

<html>
<body>
<img id='image' style='width:xx;height:xx;' src='' onmouseover="Enlarge();" onmouseout="Reduce();">
</body>
</html>

Be sure to have an image with a good resolution so that it does not pixelize when you enlarge it

----- Original Message ----
From: selyah <selyah1 at yahoo.com>
To: NYPHP Talk <talk at lists.nyphp.org>
Sent: Saturday, September 8, 2007 1:12:55 PM
Subject: [nycphp-talk] Roll ove image

Hello ;
I am in the process of completing a very complex php script and need to add a special effect using html. The effect that i have to do is a simple roll over images and upon each roll over with the mouse the images increase in size and then return back to the original size. The problem is that i am sure that this involves javascript and that is my weak point.
Therefore, i am asking anyone who can assist with a sample code or know of a link that would be helpful.
Thanks





Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com

Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070908/e10427ed/attachment.html>

[selyah]

thank you

Jon Baer <jonbaer at jonbaer.com> wrote: Probably the best way Ive seen it implemented (and easiest) would be to use the Fisheye plugin for jQuery ...


http://www.ndesign-studio.com/demo/css-dock-menu/css-dock.html


* Download link (jQuery): http://docs.jquery.com/Downloading_jQuery#Current_Release
* Download link (Fisheye): http://interface.eyecon.ro/download


(Although the SVN copy of jQuery might have the latest version of this plugin - not 100% sure)


- Jon


On Sep 8, 2007, at 1:12 AM, selyah wrote:

Hello ;
I am in the process of completing a very complex php script and need to add a special effect using html. The effect that i have to do is a simple roll over images and upon each roll over with the mouse the images increase in size and then return back to the original size. The problem is that i am sure that this involves javascript and that is my weak point.
Therefore, i am asking anyone who can assist with a sample code or know of a link that would be helpful.
Thanks
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk


NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com


Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php


_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com

Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070908/6fd5cd1c/attachment.html>

[birgunj birgunj]

Dear All,
i am uploading ebooks on my website. i want to restrict user from downloading or printing the book.user should only read the document but cant not save or download or printing.
how do we do this ? can anybody help me? its very urgent.if any software which can do it, then plz give me the name of that software also.

thanks to all in advance.

humayoo


---------------------------------
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20071001/d3e9383b/attachment.html>

[David Krings]

Post by birgunj birgunj
Dear All,
i am uploading ebooks on my website. i want to restrict user from
downloading or printing the book.user should only read the document but
cant not save or download or printing.
how do we do this ? can anybody help me? its very urgent.if any
software which can do it, then plz give me the name of that software also.
thanks to all in advance.
humayoo

There were many discussions about this in the past months and they all
resulted to this being a futile attempt. In order to display the content in a
browser the users have to download the file. This is how the WWW works.
Printing is as easy by pressing Print Screen. There are some attempts to stop
caching, obfuscating the real source URL of the file, and some tricks
disabling the most obvious functions for printing and saving, which may or may
not work depending on browser used.

As I pointed out back then, you try to solve a management problem with
technology and that never works. Your ebooks need to be priced right and be of
such a high quality that the users do want to pay you for them. If that
doesn't fit your business model, seek out avenues other than online
distribution. The only good idea that I have is self-desctructing CDs, which
yet have to be invented.

Good luck, you will need it for what you want to do.

David

[inforequest]

Post by David Krings

Post by birgunj birgunj
Dear All,
i am uploading ebooks on my website. i want to restrict user from
downloading or printing the book.user should only read the document
but cant not save or download or printing.
how do we do this ? can anybody help me? its very urgent.if any
software which can do it, then plz give me the name of that software also.
thanks to all in advance.
humayoo

There were many discussions about this in the past months and they all
resulted to this being a futile attempt. In order to display the
content in a browser the users have to download the file. This is how
the WWW works. Printing is as easy by pressing Print Screen. There are
some attempts to stop caching, obfuscating the real source URL of the
file, and some tricks disabling the most obvious functions for
printing and saving, which may or may not work depending on browser used.
As I pointed out back then, you try to solve a management problem with
technology and that never works. Your ebooks need to be priced right
and be of such a high quality that the users do want to pay you for
them. If that doesn't fit your business model, seek out avenues other
than online distribution. The only good idea that I have is
self-desctructing CDs, which yet have to be invented.
Good luck, you will need it for what you want to do.
David

Not to be contrary :-) but there is *always* a way.

In this case there are social engineering approaches to the application
of technology which work, but they don't involve PHP any more than
building an HTML form or writing a PDF file might involve PHP. No, I
won't explain them, and anyway people who look for scripts and
"software" to protect their eBook websites don't usually commit adequate
resources to execute effectively.

People log into web pages they would never want to print or distribute
every single day of the year. It's not about prevention, but persuasion.
Think about that, and you'll see some possibilities.

-=john andrews

[David Krings]

Post by inforequest
Not to be contrary :-) but there is *always* a way.

OK, then craft a web page that has something in it that disables using Print
Screen. Show me that and I'll be a believer. Until then I stand to what I
wrote earlier. OK, and not posting it on a page is cheating. ;)

David

[inforequest]

Post by David Krings

Post by inforequest
Not to be contrary :-) but there is *always* a way.

OK, then craft a web page that has something in it that disables using
Print Screen. Show me that and I'll be a believer. Until then I stand
to what I wrote earlier. OK, and not posting it on a page is cheating. ;)
David

David you have to think outside the box. It's not about technology...
it's about causing the user to not *want* to print that screen, or save
and share/email/etc. That's all I'll say ;-)

-=john

[David Krings]

Post by inforequest

Post by David Krings

Post by inforequest
Not to be contrary :-) but there is *always* a way.

OK, then craft a web page that has something in it that disables using
Print Screen. Show me that and I'll be a believer. Until then I stand
to what I wrote earlier. OK, and not posting it on a page is cheating. ;)
David

David you have to think outside the box. It's not about technology...
it's about causing the user to not *want* to print that screen, or save
and share/email/etc. That's all I'll say ;-)
-=john

Yes, and that is all I wrote in my initial reply.

David

[Rob Marscher]

Post by inforequest

Post by David Krings

Post by inforequest
Not to be contrary :-) but there is *always* a way.

OK, then craft a web page that has something in it that disables
using Print Screen. Show me that and I'll be a believer. Until
then I stand to what I wrote earlier. OK, and not posting it on a
page is cheating. ;)
David

David you have to think outside the box. It's not about
technology... it's about causing the user to not *want* to print
that screen, or save and share/email/etc. That's all I'll say ;-)

OK... now I have to know... make it include personal information
about the user (social security/credit card info/nude pictures)? I
guess photoshop could get rid of that though. Hmm....

On a more serious note, a friend recently told me what some labels
are doing with their album pre-releases to the press. Each album is
stamped with some inaudible frequency over the whole thing. Then if
the album got leaked, the label could take the leaked version, check
out which frequency is on it, and then look up who leaked it and call
in the lawyers. Of course... how long until people figure out how to
get rid of those frequencies?

Let's just make everything free. :)

[birgunj birgunj]

Dear All,
i want to make advance search engine in PHP.i have 7 fields and all fields are optional.if user select only 4 filed,then search engine will display the result according to 4 selected field.?
how to do it ? if anybody have any idea or document or book or article please share with me? its very urgent.
thanks to all in advance

humayoo


---------------------------------
Boardwalk for $500? In 2007? Ha!
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20071009/9c442487/attachment.html>

[Anthony Wlodarski]

I believe you can begin your quest for that type of knowledge here:
http://www.roscripts.com/PHP_search_engine-119.html. This is assuming that
you have worked with PHP before.



Anthony Wlodarski

aw at sap8.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20071010/c59a4776/attachment.html>