Annoucing memcache-ada 0.1
R. Tyler Croy
more:
<http://adacommons.org/Memcache>
This release of memcache-ada is the first every release of anything I've ever
written in Ada, so be gentle :)
The full listing of the supported calls can be found on the above wiki page.
Downloads:
.zip: <https://github.com/rtyler/memcache-ada/zipball/0.1>
.tar.gz: <https://github.com/rtyler/memcache-ada/tarball/0.1>
Source:
git: <git://github.com/rtyler/memcache-ada.git>
I hope somebody finds it useful, can't wait to see some examples of caching
with AWS! :D
Cheers
--
- R. Tyler Croy
--------------------------------------
Code: http://github.com/rtyler
Maciej Sobczak
> I hope somebody finds it useful, can't wait to see some examples of caching
> with AWS! :D
The biggest advantage of AWS, when compared to "traditional" web-
server hosting stateless scripts, is that AWS is stateful and being an
in-process part of the complete application makes out-of-process
caching useless.
In other words, with AWS there is no need to cache anything in a
separate process, because data can be stored for future use as a
regular object in the program. This is not just faster, but also
safer.
I have to admit, however, that web technologies are not my strongest
point and I might miss some interesting use cases.
--
Maciej Sobczak * http://www.inspirel.com
Yannick Duchêne (Hibou57)
<see.my....@gmail.com> a écrit:
You indeed at least missed an important point : there is *never* something
like stateful with web process. This is a fundamental consequence of the
client browsing process. “Stateful web server” concept makes no sense. As
the user can go back and forward in his/her navigation history, the only
possible state must be stored in pages stored in the browser, and if ever
needed, these states informations must be transmitted to the web server
via POST (preferably, personal feeling). In the web, there is a per-page
state at the client side, not a per-cession state at the server side.
Of course, many do this error to see state at the server side (and you end
up with errors and unexpected behaviors from the client point of view).
To talk about caching now, it may take place in so much multiple place
that there may not be single simple answer. Anyway, caching is in way
related to a kind of server state. Then, caching applied to static content
is not the same as caching applied to dynamically generated content. The
first may be handled by the underlying OS as much as by the server, and
the second may be as much handled by the client application as much as by
the server too.
This is not as simply a part of the server solely. This is likely to be
indeed the topic of a separate process in many cases.
--
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour
les chiens.
“I am fluent in ASCII” [Warren 2010]
Yannick Duchêne (Hibou57)
<yannick...@yahoo.fr> a écrit:
> Anyway, caching is in way related […]
Sorry, I forget a word which change the meaning. Please read “Anyway,
caching is in no way related […]”
R. Tyler Croy
Heh, that's fine, lucky for you my whole job is in web technologies ;)
Anyways, the big advantages I can see with coupling AWS with memcached by way of
memcache-ada are:
* Scaling to N web servers serving dynamic content, using a network-attached
cache such as memcached, you could have web01 do the heavy lifting generating a
page and then all the other webs (web02 - web05 for example) serve the cached
version of the page. This can be accomplished via other means via Nginx or
Varnish (for example), but neither of those will be able to cache arbitrary
chunks of computed data, merely the responses
* Providing an intermediary layer to your backing data store (MySQL, PostgreSQL,
etc). While each RDMS has some amount of in-process caching, it can't really
compare to the ability to continually add memcached instances. We use
~64GB of memcached storage at $WORKPLACE for caching various bits of data here
and there, this is at the low-end for most big web companies. Indexes can only
go so far, you can get a lot of mileage out of cheap caching of results from
your DB.
I'm not sure what AWS is capable of in terms of the Distributed Systems Annex,
but I've never found a web project that couldn't be improved by a little extra
caching here and there :)
Georg Bauhaus
> I have to admit, however, that web technologies are not my strongest
> point and I might miss some interesting use cases.
One interesting use case follows from memcached being a distributed
cache. (As was asked mentioned, AWS could be distributed via Ada.
Maybe the approaches can be combined?)
Simon Wright
> there is *never*
> something like stateful with web process. This is a fundamental
> consequence of the client browsing process. “Stateful web server”
> concept makes no sense. As the user can go back and forward in
> his/her navigation history, the only possible state must be stored in
> pages stored in the browser, and if ever needed, these states
> informations must be transmitted to the web server via POST
> (preferably, personal feeling). In the web, there is a per-page state
> at the client side, not a per-cession state at the server side.
Using AJAX, there is certainly state within one page... but even
excluding that, there clearly _is_ per-session state on the server; of
course, the browser has to identify the session concerned before the
server can know where to continue from.
pasca...@gmail.com
Yannick,
> You indeed at least missed an important point : there is *never* something
> like stateful with web process. This is a fundamental consequence of the
> client browsing process. “Stateful web server” concept makes no sense. As
> the user can go back and forward in his/her navigation history, the only
> possible state must be stored in pages stored in the browser, and if ever
> needed, these states informations must be transmitted to the web server
> via POST (preferably, personal feeling). In the web, there is a per-page
> state at the client side, not a per-cession state at the server side.
Well yes and no. In AWS the only token sent is a cookie for a per user
state.
We also support per-page state, see Web_Block technology where a MD5
is
auto-magically injected into each page. Basically:
1. there is a state on the server, user can (via the callback)
update,
a context object.
2. when sending the response to the web browser a MD5 of the full
context
data is created.
3. this MD5 is automatically injected into the response (HTML, or
XML in
Ajax XML based response).
It was not easy to get right. I have worked with Olivier Ramonat on
this part
as we wanted to have this kind to context into Vision2Pixels server.
At this
point we think it works just fine and that it is a very cool
technology.
> Of course, many do this error to see state at the server side (and you end
> up with errors and unexpected behaviors from the client point of view).
I think AWS Web_Block support is immune to that :)
Pascal.
Yannick Duchêne (Hibou57)
<pasca...@gmail.com> a écrit:
> Well yes and no. In AWS the only token sent is a cookie for a per user
> state.
>
> We also support per-page state, see Web_Block technology where a MD5
> is
> auto-magically injected into each page. Basically:
>
> 1. there is a state on the server, user can (via the callback)
> update,
> a context object.
>
> 2. when sending the response to the web browser a MD5 of the full
> context
> data is created.
>
> 3. this MD5 is automatically injected into the response (HTML, or
> XML in
> Ajax XML based response).
> I think AWS Web_Block support is immune to that :)
>
> Pascal.
Thanks for the topic, I will probably have a look at it.
pasca...@gmail.com
Yannick,
> This confirm the state has to be hold by the web page, isn't it ?
Sure, but only a single token (the key) and no need to use POST as
you said in your previous message. All data are still kept on the
server side.
Pascal.
Yannick Duchêne (Hibou57)
écrit:
> Using AJAX, there is certainly state within one page... but even
> excluding that, there clearly _is_ per-session state on the server; of
> course, the browser has to identify the session concerned before the
> server can know where to continue from.
on the involved functionality. If you are serving pages whose access
requires some right (like browsing a private forum), then it just requires
a cession state, and the server is able to hold it. On the other hand,
richer web applications (the ones I was implicitly referring too),
requires a state stored in the page, or at least a reference to a state
for that page. If the user hit the Back button, any request made from that
page will have to send the state associated with that previous page.
Imagine a user clicking a Submit button in a page retrieved from the
browser cache he/she reached after hitting Back in the browser; then
imagine he/she already click this button before he came back to it (this
is a typical case of error if the server handles the second request with
the sate associated to the last requested page).
So this depends on what kind of process is involved.
Yannick Duchêne (Hibou57)
<pasca...@gmail.com> a écrit:
> Sure, but only a single token (the key) and no need to use POST as
> you said in your previous message. All data are still kept on the
> server side.
>
> Pascal.
be a cause of resources leakage if some conditions are not waranted,
because how do you (or the server) know resources allocated for a state
can be released ? The server has no way to know if weither or not this
state is still associated to a page still opened in one tab of the browser
or in its cache. Well, I suppose this depends, as with Simon's comment, on
the kind of functionality being involved (I have the most general case in
mind).
Or else, may be a cession is allowed to have a single state only, and any
previous state is made dirty and released.
Georg Bauhaus
> "Yannick Duchêne (Hibou57)" <yannick...@yahoo.fr> writes:
>
>> there is *never*
>> at the client side, not a per-cession state at the server side.
>
> Using AJAX, there is certainly state within one page... but even
> excluding that, there clearly _is_ per-session state on the server; of
> course, the browser has to identify the session concerned before the
> server can know where to continue from.
Should there be session state in a server at all? Alternatively,
State := Server_Side.Evaluate (POST request);
if Is_Possible_State (State, Web Server Information) then
...
else
Send_Error_Indication;
end if;
A request will carry enough information to signal state assumptions.
The gist of it is that there is a finite number of possible states
(and state histories) in a web interaction. If a request
indicates one of these states (or histories), the server may
continue the interaction. If possible, it may assume the
corresponding state regardless of actual histories. (Since, in any case
a client may use multiple tabs running the "same" web interaction,
create forged requests, switch computers, exchange cookies,
switch ethernet connections, move VMs, or send request caused
by viral infections ...)
The set of possible states can change while some web interaction
is going on. Model data may have changed in the mean time, since
multiple clients concurrently update data, effects are as intended
by some request history, etc.
But there always is a set of states, and, therefore, there always
is a predicate to be called for testing a request.
Correct?
pasca...@gmail.com
Yannick,
> I see, how and within which conditions this way to do is OK. But this may
> be a cause of resources leakage if some conditions are not waranted,
> because how do you (or the server) know resources allocated for a state
> can be released ?
This is indeed a delicate problem. With AWS there is a time out
associated with
a context. It is released automatically by a running task when the
timeout is
reached.
Note that all this (context creation, injection into HTML or XML,
deletion after
time out...) is transparent to users. At the user level a context is
key/value
table with AWS.
Pascal.
Simon Wright
> Le Mon, 17 Jan 2011 11:40:12 +0100, Simon Wright <si...@pushface.org>
> a écrit:
>> Using AJAX, there is certainly state within one page... but even
>> excluding that, there clearly _is_ per-session state on the server; of
>> course, the browser has to identify the session concerned before the
>> server can know where to continue from.
>
> I see your point, you are right too. I lacked some precision: this
> depends on the involved functionality. If you are serving pages whose
> access requires some right (like browsing a private forum), then it
> just requires a cession state, and the server is able to hold it. On
> the other hand, richer web applications (the ones I was implicitly
> referring too), requires a state stored in the page, or at least a
> reference to a state for that page. If the user hit the Back button,
> any request made from that page will have to send the state
> associated with that previous page. Imagine a user clicking a Submit
> button in a page retrieved from the browser cache he/she reached
> after hitting Back in the browser; then imagine he/she already click
> this button before he came back to it (this is a typical case of
> error if the server handles the second request with the sate
> associated to the last requested page).
Yes, this is a real problem with AJAX applications; you press Back and
end up in something you'd forgotten about half an hour ago. And Forward
will not recover.
Simon Wright
> Correct?
Tyler knows much much more about this than I do!