sessions/cookies
morecowbell
i am stuck and massively confused by now trying to manage sessions and
cookies (i'll leave the mysql storage problem for another post :)
below a couple of my "problems", which are indicative of my inability
to understand the fundamentals.
1) session id seems to get rewritten every response:
class App(object):
#cherrypy.session['app'] =
@cherrypy.expose
def index(self):
#return '<html><a href="/app/check"></a></html>'
return "hello from app"
@cherrypy.expose
def check(self):
return "back to you"
conf = {'/':{'tools.sessions.on': True}}
cherrypy.tree.mount(app, '/app', config=conf)
cherrypy.quickstart()
the session id from hitting /index is different than the one after /
check . yet, firefox indicates that the stored cookie (name:
session_id, localhost, /, ...) expires at end of session. i was under
the impression that the session expires after closing the browser.
2) mounting more than one app results in the apps overwriting each
others session_id's. am i missing something? as an example, i used
above App, cloned it to App2 and
app = App()
app2 = App2()
conf = {'/':{'tools.sessions.on': True}}
cherrypy.tree.mount(app, '/app', config=conf)
cherrypy.tree.mount(app2, '/app2', config=conf)
cherrypy.quickstart()
3) i tried the setCookie/readCookie example, http://www.cherrypy.org/wiki/Cookies,
where cookie['root_app']['max-age'] = 3600. yet, firefox has Expires:
at end of session, which, sure enough is the case. shut down/start up
browser and there's no cookie left.
4) i always thought that seesions differe from cookies in that they
don't write to the client. yet, it seems that cherrypy does write a
cookie to the client, which leads me to the question: what's the
difference between a session and a cookie in cp? ... probably should
have asked that right at the beginning :)
help, heaps of help, for the feeble minded is greatly appreciated. thx.
Tim Roberts
> i am stuck and massively confused by now trying to manage sessions and
> cookies (i'll leave the mysql storage problem for another post :)
> below a couple of my "problems", which are indicative of my inability
> to understand the fundamentals.
> 2) mounting more than one app results in the apps overwriting each
> others session_id's. am i missing something? as an example, i used
> above App, cloned it to App2 and
>
> app = App()
> app2 = App2()
>
> conf = {'/':{'tools.sessions.on': True}}
>
> cherrypy.tree.mount(app, '/app', config=conf)
> cherrypy.tree.mount(app2, '/app2', config=conf)
> cherrypy.quickstart()
>
I admit to a bit of speculation here, but remember that cookies apply to
an entire tree. It may be that, because you turned on sessions at the
"/" level, the cookie is sent with the domain as "/". In that case,
that one cookie will be shared among all apps at that level and below.
Perhaps you could try:
conf = {
"/app/": {'tools.sessions.on': True},
"/app2/": {'tools.sessions.on': True }
}
but that's just speculation.
> 3) i tried the setCookie/readCookie example, http://www.cherrypy.org/wiki/Cookies,
> where cookie['root_app']['max-age'] = 3600. yet, firefox has Expires:
> at end of session, which, sure enough is the case. shut down/start up
> browser and there's no cookie left.
>
Were you doing this by itself, or did you have sessions turned on?
> 4) i always thought that seesions differe from cookies in that they
> don't write to the client. yet, it seems that cherrypy does write a
> cookie to the client, which leads me to the question: what's the
> difference between a session and a cookie in cp? ... probably should
> have asked that right at the beginning :)
>
A "session" is just a concept. It is a way to store information that
can be passed from request to request. In order to provide session
functionality to client apps, web frameworks have to be able to know
which HTTP requests are related. That can be done in several ways. One
way is to embed a session ID in each URL. The easiest way is to send
the session ID in a cookie.
So, it's not like "sessions" and "cookies" are alternatives to each
other. Rather, cookies are just one mechanism for implementing sessions.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Robert Brewer
> A "session" is just a concept. It is a way to store information that
> can be passed from request to request. In order to provide session
> functionality to client apps, web frameworks have to be able to know
> which HTTP requests are related. That can be done in several ways.
> One
> way is to embed a session ID in each URL. The easiest way is to send
> the session ID in a cookie.
>
> So, it's not like "sessions" and "cookies" are alternatives to each
> other. Rather, cookies are just one mechanism for implementing
> sessions.
Well, it is a bit muddier. Sessions are a place to stick data
(server-side). Cookies are a place to stick data (client-side). You can
use either for almost anything. But often, the only thing you stick in
the cookie is a (secure) pointer/identifier to the session.
Robert Brewer
fuma...@aminus.org
brahmaforces
1) If I set a cookie or session variable in my python cherrypy code,
will I be able to detect it using javascript on the client side and
get its value?
2) If the above is true which is preferable cherrypy session or cookie
to pass data between the server and the client.
3) I am forced to use an alternative mechanism because while using
ajax on the client side as follows:
function addFriend(addFriendId) {
xmlhttp8 = getXmlHttpRequest();
var qry='addFriendId=' + addFriendId;
var url='addToFriends?' + qry;
xmlhttp8.open('GET', url, true);
xmlhttp8.onreadystatechange=displayAddedFriendsProfile();
xmlhttp8.send(null);
}
function displayAddedFriendsProfile() {
If I try to pass a variable x from displayAddedFriendsProfile(x) , to
function displayAddedFriendsProfile(x), for some strange reason it
breaks and does nothing. Therefore I am forced to return the value of
x from the server. But the response from the server is captured in
ResponseText, so I can return only one string of values. Therefore I
am forced to put this in a session of cookie.
I should be able to pass a variable from server to client in a simpler
way. Are sessions cookies the right solution? This should have been
allowed in Javascript in the first place, because its simply one js
function passing a variable to another js function as a parameter...?
arjuna
It seems that 1) answered itself and the answer is a BIG YES. If we set a cherry
py cookie using cherry speak to do it, we can use javascript to find it, because a cookie is ar cookie, cherrypy or java!
3) Off topic but neverthless, it seems that the
xmlhttp8.onreadystatechange=
displayAddedFriendsProfile();
function is not a js function but the name of the js function that is to be called when the readyState changes and should be articulated as such:
xmlhttp8.onreadystatechange=
displayAddedFriendsProfile
arjuna
morecowbell
figures that out automatically,
just as rails does. my bad.
>
> > 3) i tried the setCookie/readCookie example,http://www.cherrypy.org/wiki/Cookies,
> > at end of session, which, sure enough is the case. shut down/start up
> > browser and there's no cookie left.
>
> Were you doing this by itself, or did you have sessions turned on?
>
a) the cookie generated by setCookie and
b) the cookie holding the session id
> > 4) i always thought that seesions differe from cookies in that they
> > don't write to the client. yet, it seems that cherrypy does write a
> > cookie to the client, which leads me to the question: what's the
> > difference between a session and a cookie in cp? ... probably should
> > have asked that right at the beginning :)
>
> A "session" is just a concept. It is a way to store information that
> can be passed from request to request. In order to provide session
> functionality to client apps, web frameworks have to be able to know
> which HTTP requests are related. That can be done in several ways. One
> way is to embed a session ID in each URL. The easiest way is to send
> the session ID in a cookie.
>
> So, it's not like "sessions" and "cookies" are alternatives to each
> other. Rather, cookies are just one mechanism for implementing sessions.
>
concrete example:
login with basic_auth
i am using basic_auth, tools.seesions.on. all works well. i log in and
a session cookie shows up on the client. all is well. however, when i
delete the session cookie on the client, i expected a new login
request. not so. instead i just got a new session cookie on the
client. moreover, i tried to expire the session on the server with
tools.sessions.timeout=1 , where i expected that after 1 minute or so,
given the auto-lock/release margins, the session would expire and a
new login request presented to client, which didn't happen. i also
tried cherypy.lib.session.expire = True to force an end to the session
but also no luck.
things got worse when i tried to correlate a session with ah html form
submission.
any insights are greatly appreciated.
> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.
Tim Roberts
> Folks,
>
> It seems that 1) answered itself and the answer is a BIG YES. If we
> set a cherry
> py cookie using cherry speak to do it, we can use javascript to find
> it, because a cookie is ar cookie, cherrypy or java!
The answer is "half yes," not "BIG YES". Yes, you can read cookies from
Javascript. However, a session variable is stored within the CherryPy
process on the server side. It is not transmitted to the client. The
cookie is just a way for CherryPy to go find the stored session data for
this session
>
> 2) Since sessions use cookies for implementation why not use cookies
> directly?
Do you mean, for session data? Because the entire contents of each
cookie for the site are sent by the browser with EVERY request it makes
from your web site. If your HTML code has references to 20 little GIF
images, the cookies will be transmitted 21 times. Since session data
can potentially be large, the disadvantage should be obvious.
Tim Roberts
>
> i'm seemingly not getting this at all. pls let me give you a more
> concrete example:
>
> login with basic_auth
> i am using basic_auth, tools.seesions.on. all works well. i log in and
> a session cookie shows up on the client. all is well. however, when i
> delete the session cookie on the client, i expected a new login
> request. not so. instead i just got a new session cookie on the
> client. moreover, i tried to expire the session on the server with
> tools.sessions.timeout=1 , where i expected that after 1 minute or so,
> given the auto-lock/release margins, the session would expire and a
> new login request presented to client, which didn't happen. i also
> tried cherypy.lib.session.expire = True to force an end to the session
> but also no luck.
>
basic_auth authentication has nothing to do with either cookies or
sessions. Remember that basic_auth works with straight HTML pages,
where there is no scripting at all. It is a separate, private
communication between the web server and the browser. There is no way
from the server side (that I am aware of) to force a basic_auth login to
expire.
If you want logins to expire, you need to throw out basic_auth
authentication and do the authentication yourself, by remembering the
validated user name in your session variable. That way, when you force
your cookie to expire, your remembered login name will go away, and you
can bring up your own login page.
> things got worse when i tried to correlate a session with ah html form
> submission.
>
I don't understand that. Once you have a cookie-based session, you
should have your session data available for every request, either GET or
POST.
Christian Wyglendowski
>
> arjuna wrote:
>> 2) Since sessions use cookies for implementation why not use cookies
>> directly?
>
> Do you mean, for session data? Because the entire contents of each
> cookie for the site are sent by the browser with EVERY request it makes
> from your web site. If your HTML code has references to 20 little GIF
> images, the cookies will be transmitted 21 times. Since session data
> can potentially be large, the disadvantage should be obvious.
It's a good idea to turn off sessions on your static-serving
subdirectories unless you absolutely need them.
That said, there are other reasons you wouldn't want to send the
session data in the actual cookie. You probably don't want someone
tampering with the data in the cookie and then sending it back. That
might do Bad Things to your app. Rails uses cookies as session
stores, but it encrypts the data, thus making reading it on the
client-side not possible (unless you do decryption client-side as
well, and then you're back to square one).
So yeah, what Tim said - keep your sessions on the server.
Christian
http://www.dowski.com
Paweł Stradomski
> Rails uses cookies as session
> stores, but it encrypts the data, thus making reading it on the
> client-side not possible (unless you do decryption client-side as
> well, and then you're back to square one).
Well. AFAIK Rails only sign session cookies, but does not encyrpt them (as
opposed to ex. beaker, which can do both). This means the cookie can be read,
but not tampered with. The data in the cookie looks like garbage only because
of Ruby serialization format, which is less readable than python's pickle.
--
Paweł Stradomski
arjuna
Sorry about so many questions, but this is getting confusing given that we have cherrypy, mako, javascript, and two varieties of sessions and cookies involved as ingredients in the Cherry pie! :)
Paweł Stradomski
> Folks:
> Sorry if I sound simplistic, a bit of which I am, when it comes to thinking
> about programming, correct me if i am wrong:
>
> Sessions and cookies are both expensive in terms of resources. Sessions
> should be avoided and turned off as much as possible
Let's don't overestimate the problem.
> Say I have a user logged into my system. I store his user ID in a client
> cookie. I am using a lot of ajax for data going back and forth, the page
> almost never refreshes. Does this mean the cookie is going to be thrown
> about between the client and the server like a squash ball in a squash
> court?
Every request from the browser will contain the cookie. The response will only
contain it if it changes.
Also note, that you can not trust the data that comes from the cookie - it
should be treated as possibly malicious, just like data in the POST body and
query string. So I'd rather store the user id in the session, not in the
cookie, or use signed cookies (there is no built-in support for that in
cherrypy, although it can be easily done).
> If it is expensive, then what can I use to maintain state on the client
> side? Eq if a user is logged in how do i track it. Also if the session
> handling is on the server side, and I cannot access it on the client side,
> then should I be using my templating engine in this case mako to access
> server side variables and then using javascript to access those variables
> to make choices on the client side.
If both client and server need to know the same shared state, then something
is probably wrong. I've never needed to access cookie data in the javascript.
>
> SHould I be using javascript sessions and cookies? Are these different from
> cherrypy sessions and cookies? Are they more economical to use?
There are no javascript sessions. After a page is reloaded, all javascript
state is dropped for the reloaded frame/window. There are no javascript
cookies - it's just that javascript can access the cookie data that is
transferred to and from the server.
> Sorry about so many questions, but this is getting confusing given that we
> have cherrypy, mako, javascript, and two varieties of sessions and cookies
--
Paweł Stradomski
Robert Brewer
> W liście arjuna z dnia niedziela, 7 września 2008:
> > thinking about programming, correct me if i am wrong:
> >
> > Sessions and cookies are both expensive in terms of resources.
> > Sessions should be avoided and turned off as much as possible
>
> Let's don't overestimate the problem.
Robert Brewer
fuma...@aminus.org
arjuna
> side? Eq if a user is logged in how do i track it. Also if the session
> handling is on the server side, and I cannot access it on the client side,
> then should I be using my templating engine in this case mako to access
> server side variables and then using javascript to access those variables
> to make choices on the client side.
is probably wrong. I've never needed to access cookie data in the javascript.
Arnar Birgisson
> If both client and server need to know the same shared state, then something
> is probably wrong. I've never needed to access cookie data in the
> javascript.
Why? The mechanism to read and set cookies is there in JS, there's
nothing wrong with using it.
> Normally I would just have passed the variable fro, the server to the client
> as a straight variable. The complication is in using AJAX where I return one
> variable from the server and the variable contains the response to the AJAX
> request. So I use responseText in javascript to gather that. This means I
> cannot send back other variables to the server in an ajax call. I could add
> them in the one variable that i am sending back to the client and parse it
> in javascript to extract it. But thats doing too much.It seems inelegant and
> goes against the pythonic objective of being lazy :). So if I can only pass
> one variable from the server to the client in an ajax call, then i need to
> put the other variables that i need to pass to the client somewhere else.
There is absolutely no restriction that says you can pass only one
variable in the result. Packing up a lot of data in a string and then
parsing it is quite common practice. I'd recommend using JSON, as
parsing it on the client side requires nothing more than a call to
eval(). Also, if you are using some JS-library, most of them have
conveniece methods for making an Ajax call and parsing the result as a
JSON string.
To create JSON on the server side, look up simplejson.
> For now i have put it in a cookie which i look up in the javascript. Do you
> think this is a valid approach or should i be :
> 1) Putting it in a session and getting that in javascript. But you are
> saying javascript cannot pick up server session variables so this seems out.
The "session" is an dictionary on the server side. These dictionaries
are identifed with the session id, which is stored in a cookie. So
unless you specificly stuff all your session data in cookies yourself,
the session ID is really the only thing you can access from JS.
Needless to say, that is of little use on the client side.
> 2) Putting it with the single variable i am returning from the client to the
> server. The single variable contraint seems to happen in ajax where the
> client uses that variable as "responseText". Then proceed to parse of client
> side and do a bunch of inelegant hacking.
> Am I missing a really simple straight solution here?
Yes, the standard practice today is indeed to serialize everything
into a string, read it from responseText and parse it into individual
variables. As mentioned above, JSON makes this trivial.
cheers,
Arnar
arjuna
First let me thank everyone for their response and help! It is indeed invaluable.
So what i have learned from Robert is that cookies and sessions are expensive in http even though you may not notice it initially, but this is something that may come up when the code is deployed and doing heavy lifting.
Arnar, so parsing the string seems like the way to go. I will look up json. Am trying to avoid yet another frameworkin the mix. I am managing with straight javascript. I have written all the ajax and everything directly. But i guess it wouldnt hurt to explore whats out there in terms of js frameworks.Any recommendations for good frameworks?
Robert Brewer
> So what i have learned from Robert is that cookies and sessions
> are expensive in http even though you may not notice it initially,
> but this is something that may come up when the code is deployed
> and doing heavy lifting.
That's not what I meant at all. Cookies that only contain a session id
are cheap. No reason not to use them.
Robert Brewer
fuma...@aminus.org
Arnar Birgisson
> But i guess it wouldnt hurt to explore whats out there in terms of js
> frameworks.Any recommendations for good frameworks?
My favourite right now is jQuery: http://jquery.com/
If you like Python, MochiKit is also pretty good: http://mochikit.com/
cheers,
Arnar
Tim Roberts
>
> So what i have learned from Robert is that cookies and sessions are
> expensive in http even though you may not notice it initially, but
> this is something that may come up when the code is deployed and doing
> heavy lifting.
You are choosing to misunderstand what is being said here. There is no
heavy lifting. Come on -- do the math. An "id" cookie is typically a
dozen or two bytes. Unless you are running on a 300 baud modem, adding
two dozen bytes to each HTTP request represents an insignificant
additional burden on your bandwidth. Even if you are getting 1,000
requests a second, a 32-byte cookie isn't going to be noticed.
The facts are simple. If you hope to maintain any kind of session
state, then you must find a way to uniquely identify all requests from a
given client. To do that, you must induce the client to send you some
kind of unique identifier with each request. To do THAT, you can
either do it yourself, by adding to the URL or using a variable in each
POST, or you can use a cookie. In either case, you are adding rouhgly
the same number of bytes to each request. There is no free lunch.
Once you accept that, you can look at the available alternatives.
Cookies are ubiquitous and automatic. Because of that, I think they are
an excellent way to go.
> Arnar, so parsing the string seems like the way to go. I will look up
> json. Am trying to avoid yet another frameworkin the mix. I am
> managing with straight javascript. I have written all the ajax and
> everything directly. But i guess it wouldnt hurt to explore whats out
> there in terms of js frameworks.Any recommendations for good frameworks?
Be very careful about tightly coupling your Javascript and your server
code. It's very easy to make such a combination complicated and
delicate. Browsers are unpredictable. Also remember that, if you hope
to appeal to a wide audience, a certain percentage of your users will
have Javascript disabled. In that case, you need to think about having
your site work even without AJAX.
I tend to fall back to AJAX only as a last resort. Round-trip times
today are typically good enough that most sites don't absolutely require it.
arjuna
Thanks for the low down on the cookie. Will not hestitate to use it from now on. I guess I ended up using parameter variables in the query string. I also got the JSON working in the AJAX to transfer data back and forth. It really is as simple as an eval statement in js.
Regarding AJAX, I am making an art site and am targeting people with modern browsers. The site will not work without JS enabled and it is heavily dependent on AJAX. I have one public page and one password protected page. Almost all the action happens on 1 password protected page, with different div tags being loaded using AJAX. Thats just the nature of my app...
Thanks for the help and advice.
Tim Johnson
> to appeal to a wide audience, a certain percentage of your users will
> have Javascript disabled. In that case, you need to think about having
> your site work even without AJAX.
screaming to it. We make it a practice that any content rendered - whether
dynamic or static have a noscipt tag and a redirect to a help page for those
who might have javascript turned off.
>
> I tend to fall back to AJAX only as a last resort. Round-trip times
> today are typically good enough that most sites don't absolutely require
> it.
that is many times "taller" than the screen and has several hundred fields
for input or editing. To refresh the page is intolerable to the user - since
their place would be lost - so we post via ajax - send an alert box to the
user when the save is finished. Saves take about .15 seconds on the average
versus about 7 seconds on a 500K DSL connection - pretty standard in Alaska.
I just finished reading and writing a report on "Dojo - The Definitive Guide"
by O'Reilly. All of the server-side code examples use cherrypy.
I predict that as time goes by, there will be a greater demand for client-side
scripting and a comparative reduction in demand for server-side scripting.
I wish I were wrong, 'cuz I really like python and don't like coding in
javascript.
regards
Tim Johnson
Alaska Internet Solutions
Tim Roberts
> I just finished reading and writing a report on "Dojo - The Definitive Guide"
> by O'Reilly. All of the server-side code examples use cherrypy.
> I predict that as time goes by, there will be a greater demand for client-side
> scripting and a comparative reduction in demand for server-side scripting.
>
> I wish I were wrong, 'cuz I really like python and don't like coding in
> javascript.
>
Yes, I agree, for a couple of additional reasons.
Complexity is not a good thing. Synchronous web applications are
simple. Simple to understand, simple to construct. The
one-request-one-answer paradigm puts a very tight limit on the amount of
state that's dangling around and the number of paths that the app can
take, all of which makes it possible to write even large applications
that are relatively easy to understand, and are self-contained enough
that they can be proven correct. At the turn of the century, I was
actually migrating many of my desktop applications to web applications
because this simplicity was so compelling.
Adding AJAX to the mix ruins that. Even if you are a programming
wizard, and I immodestly count myself in that group, AJAX makes things
freakin' complicated. You are now deeply involved in client/server
programming, with complicated inter-process communication. (Yes,
technically a CGI script is part of a client/server communication, but
that's all hidden from me.) State is split between the server and the
client in ways that are not yet standardized and somewhat difficult to
secure.
Perhaps, in a couple of years, the web world will standardize on a basic
AJAX library, so that the browser becomes less of a blank slate and more
of a standardized toolkit. At that point, dynamic web applications will
be fun again.
Arnar Birgisson
On Tue, Sep 9, 2008 at 22:37, Tim Roberts <ti...@probo.com> wrote:
> Yes, I agree, for a couple of additional reasons.
>
> Complexity is not a good thing. Synchronous web applications are
> simple. Simple to understand, simple to construct. The
> one-request-one-answer paradigm puts a very tight limit on the amount of
> state that's dangling around and the number of paths that the app can
> take, all of which makes it possible to write even large applications
> that are relatively easy to understand, and are self-contained enough
> that they can be proven correct. At the turn of the century, I was
> actually migrating many of my desktop applications to web applications
> because this simplicity was so compelling.
>
> Adding AJAX to the mix ruins that. Even if you are a programming
> wizard, and I immodestly count myself in that group, AJAX makes things
> freakin' complicated. You are now deeply involved in client/server
> programming, with complicated inter-process communication. (Yes,
> technically a CGI script is part of a client/server communication, but
> that's all hidden from me.) State is split between the server and the
> client in ways that are not yet standardized and somewhat difficult to
> secure.
I've in fact taken the opposite direction. Many of my newer apps
utilized the browser as a GUI platform only, while application logic
took place on the server and communication between them was through
some ad-hoc json-based API. This works pretty well and results in more
intuitive and responsive web appliations in my case.
Decoupling front- and back-ends of applications is not a new concept,
and is even favored in many circumstances. I don't see why
web-applications can't use methods and paradigms developed throughout
the years. What matters is a clean interface (API) between the
frontend and the backend, which is relatively easy to design in many
cases. Once you get in the habit of thinking of the browser as GUI
platform loosely coupled with the appliation itself, things can
actually work out quite nicely. The browser needs not keep any state,
except for presentation purposes, and certainly not between page
requests (I use "page requests" to distinguish from ajax requests).
With Python on the server side and JS (preferably some library) on the
client side, it is also easy to set up a small API framework where it
is easy to clearly define the interface between the browser and the
server. The web application then becomes two parts, one is the part
serving up pages - which become few and stupid, essentially dealing
mostly with authentication and serving up bytes, and on the other hand
an application programming interface. If this is correctly designed,
the API can even be used by richer client frameworks or other servers
(I've used this quite a bit with server-to-server communication where
two seperate webapps delegate some services to each other).
My point is, Javascript is here to stay, and can be quite useful in
the right context. If you are building an actual web-application, as
opposed to a website mainly as a marketing tool or an information
source, there is in my opinion no harm today to say "This website uses
Javascript, please turn it on."
cheers,
Arnar
Gloria W
interesting:
http://code.google.com/apis/protocolbuffers/
If proper AJAX support is added, this could be useful on the server
side. It may also turn out to be too bloated, ruining the elegance and
simplicity of JSON. In either case, it's fun to read the comments and
watch people play with it.
Gloria
Arnar Birgisson
On Tue, Sep 9, 2008 at 23:10, Gloria W <stra...@comcast.net> wrote:
> Google is attempting to standardize on JSON transaction models, which is
> interesting:
> http://code.google.com/apis/protocolbuffers/
> If proper AJAX support is added, this could be useful on the server
> side. It may also turn out to be too bloated, ruining the elegance and
> simplicity of JSON.
ProtocolBuffers are not meant to replace JSON, they are just an
efficient binary serialization format. The main thing that seperates
ProtocolBuffers from other formats is version independence of
messages, i.e. as long as you follow some simple rules for updating
message descriptions, old messages remain valid on new descriptions
and vice versa. Apart from that, PB can be likened to Adobe's AMF.
If browser start supporting ProtocolBuffers natively and provide the
interface for it to JS, they might very well become a good alternative
to JSON, XML or ad-hoc text formats, but I think Google's intentions
are different for now. HTTP performance is still the bottleneck so
there is little to gain from more efficient data formats.
cheers,
Arnar
arjuna
>wizard, and I immodestly count myself in that group, AJAX makes things
>freakin' complicated. You are now deeply involved in client/server
>programming, with complicated inter-process communication. (Yes,
>technically a CGI script is part of a client/server communication, but
>that's all hidden from me.) State is split between the server and the
>client in ways that are not yet standardized and somewhat difficult to
>secure.
I agree with you that maintaining state on the client and the server is a pain, because both must be handled separately. I was doing this by passing query parameters back and forth that include state information. This is not straightforward, because of redirects to public pages if the user is not logged in and other such issues...
However, yesterday I had the idea that a cookie seems like a good way to synchronize state between client and server because it is accesible both by python/cherrypy on the server side and javascript on the client side.
I am not currently using a javascript framework but am programming it directly. I havent found any frameworks that seem to add value beyond their own learning curve. Ie given my limited knowledge of js frameworks, it seems that the frameworks add more complexity as their nuances have to be learned, while the same effect can be achieved with a few lines of js code I checked of Mochit and jquery they dont seem to have anything substantial to offer, do correct me if i am wrong here.
Tim Roberts
>
> It seems that AJAX is necessary not from a technical perpective but a
> user perspective. On web applications that have a lot of functionality
> and client server communication page refreshes seem obsolete.
This is an interesting point. In actual fact, AJAX is never a user
requirement. A proper specification will never say "the site must use
AJAX". Instead, the specification will talk about the user experience,
and acceptable response times, and things like that. It might be that
the requirements can only be achieved today by using AJAX, but they also
might be possible through some simpler means.
By the way, I've enjoyed this thread very much. My AJAX dabbling has
always been rather frustrating, and I have appreciated learning about
the design philosophies expressed here.
Tim Johnson
> This is an interesting point. In actual fact, AJAX is never a user
> requirement. A proper specification will never say "the site must use
> AJAX". Instead, the specification will talk about the user experience,
> and acceptable response times, and things like that.
Ajax is just javascript. Thus if javascript
is enabled, ajax is enabled (given the codebase)
> By the way, I've enjoyed this thread very much. My AJAX dabbling has
> always been rather frustrating, and I have appreciated learning about
> the design philosophies expressed here.
dojo advertises that any discrepancies between browsers is handled by
it's libraries - including client/server communication (ajax) and ancillary
issues,
plus dom navigation. We've decided to start using it where necessary -
at least on a test basis
> It might be that
> the requirements can only be achieved today by using AJAX, but they also
> might be possible through some simpler means.
- And I'm open to that. I've also noted that Craig's List seems to be a very
successful site and it uses _very_ simple approaches. I would think that
a customized server + good server handling might be an acceptable alternative.
Tim
Tim Johnson
> - And I'm open to that. I've also noted that Craig's List seems to be a
> very successful site and it uses _very_ simple approaches. I would think
> that a customized server + good server handling might be an acceptable
> alternative.